Ned

just post it here? or put it on dropbox/google drive and share us a link?

nah, not yet. Was just doing the easy bits. I reall;y just wanted an excuse to get into the garage for the afternoon and didnt wanna pul;l TOO much off of it as i plan on riding it around regularly still

I invited young Sparky over to my place to ride the lead and see if it's actually slow, or if im too fat. It's just slow. So me and Sparky spent hours this weekend pulling the Lead to pieces, clean up the carb, burn out the exhaust, clean the blocked jets and put in a new plug (the old one was gapped to 0.15mm instead of the 0.6-0.7 Honda recommends) Put it all back together and took it for a hoon and guess what!? It's slower/the same oh well, time to pull the head i guess

mechanical switches bounce, thats just the nature of them. Add SW debouncing by checking the signal is valid for 30mS or something, or do hardware debouncing with a 100nF capacitor across the switch and a weak pullup? 10k or bigger maybe? i dont usually do HW debouncing as it costs more than a few lines of code so might pay to google a bit....

or even change the defines to this: #define TEMP_BAND 2 #define TEMP_MINOR 24 #define TEMP_GENERAL 28 #define TEMP_DIRE 32 #define INCR_MINOR (TEMP_MINOR) #define INCR_GENERAL (TEMP_GENERAL) #define INCR_DIRE (TEMP_DIRE) #define DECR_IDLE (TEMP_MINOR - TEMP_BAND) #define DECR_MINOR (TEMP_GENERAL - TEMP_BAND) #define DECR_GENERAL (TEMP_DIRE - TEMP_BAND) and it will fire the error as soon as it happens, but wont 'clear' it until it's gone lower by the deadband

You can change TEMP_BAND from 2 to 1 to lower the deadband, and then it will be 'faster' you can also remove or lower the delay, as it only sends stuff when stuff changes, so wont bombard the serial port as much probably

it looks like it has some weird character in between the # and the define part? maybe try re-writing it as a copy/paste might be putting some weird shit in there from the interwebs? Wont need a library or anything https://www.arduino.cc/reference/en/language/structure/further-syntax/define/

ok, try this (i havent compiled it, so might have the odd error, but should give you an idea/starting point) #define TEMP_BAND 2 #define TEMP_MINOR 24 #define TEMP_GENERAL 28 #define TEMP_DIRE 32 #define INCR_MINOR (TEMP_MINOR + TEMP_BAND) #define INCR_GENERAL (TEMP_GENERAL + TEMP_BAND) #define INCR_DIRE (TEMP_DIRE + TEMP_BAND) #define DECR_IDLE (TEMP_MINOR - TEMP_BAND) #define DECR_MINOR (TEMP_GENERAL - TEMP_BAND) #define DECR_GENERAL (TEMP_DIRE - TEMP_BAND) enum warningStates_t {IDLE = 0, WARN_MINOR, WARN_GENERAL, WARN_DIRE}; warningStates_t curState, oldState; void loop() { thermoSensorNewVal = thermoSensor.readCelsius(); if (thermoSensorNewVal != thermoSensorOldVal) { Serial.print(" C = "); Serial.print(thermoSensorNewVal); thermoSensorOldVal = thermoSensorNewVal; } switch (curState) { default: curState = IDLE; /* should never happen, but good practice to have a default */ case IDLE: if (thermoSensorNewVal >= INCR_MINOR) curState = WARN_MINOR; break; case WARN_MINOR: if (thermoSensorNewVal <= DECR_IDLE) curState = IDLE; if (thermoSensorNewVal >= INCR_GENERAL) curState = WARN_GENERAL; break; case WARN_GENERAL: if (thermoSensorNewVal <= DECR_MINOR) curState = WARN_MINOR; if (thermoSensorNewVal >= INCR_DIRE) curState = WARN_DIRE; break; case WARN_DIRE: if (thermoSensorNewVal <= DECR_GENERAL) curState = WARN_GENERAL; break; } if (curState > oldState) { // Increased temp warnings switch (curState) { case WARN_MINOR: tempWarningMinor(); break; case WARN_GENERAL: tempWarningGeneral(); break; case WARN_DIRE: tempWarningDire(); break; default: break; /* should never happen, but good practice to have a default */ } } if (curState < oldState) { // Decreased temp warnings switch (curState) { case IDLE: /* Could do an 'all clear' message here */ break; case WARN_MINOR: tempWarningMinor(); break; case WARN_GENERAL: tempWarningGeneral(); break; default: break; /* should never happen, but good practice to have a default */ } } oldState = curState; delay(1000); } // end of loop So made a few changes for you. 1) the value being output by your serial debugger is the value actually used for the comparing (before you would re-read it) 2) it will only print out the temperature if it has changed 3) state machine based, so it will only fire each warning once 4) added some defines so you can easily change the values all in one place. How it works is when it's in a state (like IDLE) it will only look for one thing... and that is "Is it hot enough to fire a Minor warning?" and if it is, it sets the state to WARN_MINOR and will fire off that warning. Now the state is WARN_MINOR and now it does 2 things. "Is it cold enough to go back to Idle?" and "Is it hot enough to go to WARN_GENERAL?" If so, it changes the states accordingly. The warnings are sent using the oldState and the curState. So if they are ever different, it will fire a warning. And it checks to see if the state is going up or down, so you can do different warnings for going up and going down if you like

You want what they call a state machine. Im on my phone and dont wan a write code on it haha but will help out if you're still stuck Monday

why not use structs? typedef struct screenValues_t { uint16_t speed, rpm, tp, wb02; int16_t iat; } screenValues_t; screenValues_t oldScreen, newScreen; // copy all the current data into the old one memcpy(&oldScreen, &newScreen, sizeof(screenValues_t)); // do stuff with things? if (newScreen.rpm != oldScreen.rpm) { // have a dance }

I have a couple nice supplies here already. Next one will be a high current one (like 30A) i think... China has some affordable ones... But you sure it's not the output cap doing that? They all have an output cap thats fully charged, so if you have it set to 5V 0.01A to connect an LED and current limit it to 0.01A, you still have a fully charged output cap at 5V that will smoke the LED... Dont think theres anything to do about that? I blew up a fancy LED in a reps display box that way he wasnt happy hahaha

Lexy has a little Mazda Premacy that is supposedly a 7 seater... but you better be a small person for the back seats though! but you all ride small bikes so should be fine? It also has a teeny tow bar for a teeny trailer (but i dont has trailer). I realistically wont do anything to the scoot as too much other shit to spend time and money on... but keen to potentially partake in shenanigans somehow. Plus @sentra will break down on day 1 and we can have a 2 day vengaboys sing along party! So don't rely on me as support vehicle, but when push comes to shove, i can 100% be bullied into attending

one day.... one day....

how is it wired up? Looks like there is a connection on the rectifier not being used??

i told you to throw that diode in the bin Peter... you better not put that in... you could solder wires with glue lined heat shrink to the cap, cable tie them to the cab as strain relief. Then crimp spade terminals to the wires to go to the bridge rectifier? Bolt the bridge rectifier to something metal as a heat sink? A bit of water will be fine, as long as it's not submerged. You could put some dielectric grease on the connections if you're worried about water

I'm glad youre keeping the dream alive Ben!!!

probably needs a lot of things TBH... might not be a bad idea to pull it apart and give it all a once over one day haha

with 10-5 riding it maybe... with me i can get 65 out of it on a flat road with no wind or a tail wind... but i sit at 60, or just over most the time

im kinda keen to go, but my scoot tops out at 60 and i dont wanna be the slow guy at the back of the pack

Where are your 18V spikes? oin the power supply or the input pin for the micro? I would do this; a) create a good power supply with some decent input caps, a diode and a zener to try smooth out some real nasties... This has a lot of 4.7uF because thats on the bigger end of surface mount... just use some big through hole 10uF or 22uF even... Then do some input protection on all of your pins that connect to car stuff. This is for ADC inputs from 0-5V that need a pullup, like IAT and coolant sensors etc For a hall effect, i would use this and for VR, you will need to get a MAX9926 like this (they have modules) To drive the coils, this is a pretty decent chip i've used in the past. Oviously the 0R to the 2 supplies is so you can pick, only connect one of those and pick the driver you want with either inverting or non inverting outputs All of this came from an ECU i designed and built, but never got running!! so none is tested properly, but it is all based heavily on speeduino, FreeEMS and MicroSquirt etc (they are all 90% the same anyway) so should be a good starting point for (semi) reliable electronics that run in cars

oh man, good luck! you are now diving into the single worst system in electronics... car ignition shit. Car power is hard because the power supply is NOISY and shit. Add to that a VR sensor or something (which has a 150V signal BTW) and you're up shit creep in regards to noise and weird voltage offsets yada yada yada... Share some schematics of what you have and i'll have a peek, but fuck, what a project to tackle hahaha

Yeah, that shit no work. What trying to do?

also at vinegar hill that weekend What speed do i have to be able to do to safely do this ride? im tapped out at 65-70 on the flat... slows down a touch for casual hills and more for big hills. Hill starts are just about a non starter lol

looks good. Just a couple tips (some controversial and waiting for @h4nd to tell me im wrong ) replace if (IncrementCounter == 9000) { IncrementCounter = 0; } with >= 9000 so it still works if it ever skips 9000. I know it wont skip 9000, but there is a reasonable chance that at some point you'll be like "fuck, this takes ages, i wonder how the thing looks when i increase the values heaps and fast?" and change the IncrementCounter = IncrementCounter + 1; to IncrementCounter = IncrementCounter + 5; just for kicks, and then shit will no longer work right and second, your variable naming techniques this is the controversial part as everyone has their own standard... but most people will start their variable names with a lower case, so its easy to differentiate from function names. so IncrementCounter to most looks like a function, whereas incrementCounter would be a variable. It's especially handy in IDEs like the arduino one as it doesnt do auto complete and function complete things etc, so it just reads a bit easier and helps you make less mistakes.

no problem man, happy to help and yeah, sooooo much shit you can do! lemme know if you get stuck or have any questions man Keen to see how it pans out etc! you going to put any real indication light on etc? like the blue high beam you legally need on your dash?