Ned

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?

oh man, Dave, damn! That dash looks fucking COOOOOL some shit yarns about conditioning signals Averaging, or only displaying in increments of 100 doesnt make it flicker any less as you'll end up sitting at 2499-2501 and it will still flicker between 2400 and 2500 constantly. Better option is windowing your readings with hysteresis or just simply time based... like this? #define RPM_HYSTERESIS (25) #define RPM_TIME_INTERVAL (100) uint16_t displayRPM; uint32_t rpmTimeout, currentTime; loop { currentTime = millis(); if ((max(rpm, displayRPM) - min(rpm, displayRPM)) > RPM_HYSTERESIS) { rpmTimeout = currentTime; displayRPM = rpm; } if ((currentTime - rpmTimeout) >= RPM_TIME_INTERVAL) { rpmTimeout = currentTime; displayRPM = rpm; } } that way you get rapid change when accel/decel, and get real values displayed on the screen occasionally but not heaps? if you wanna do rpm with blocks of 100rpm, use hysteresis to make it jump though like so; uint16_t displayRPM; #define RPM_BLOCK_SIZE 100 #define RPM_HYSTERESIS ((RPM_BLOCK_SIZE / 4) * 3) loop { while (rpm > (displayRPM + RPM_HYSTERESIS)) { displayRPM += RPM_BLOCK_SIZE; } while (rpm < (displayRPM - RPM_HYSTERESIS)) { displayRPM -= RPM_BLOCK_SIZE; } } theres faster ways to do that than use a while, but this way is easy to understand what it's doing. you can also just repalce the while with is and replace displayRPM += RPM_BLOCK_SIZE with displayRPM = rpm. It's faster and more efficient, but it wont display the nice round increments. you can use that same system with all the numbers to stop them from flickering if you wanna update them in block sizes. Hope that helps? You're fast getting into the rabbit hole of coding haha. This is where you find a whole new set of challenges

theres a video chip you can still get from china. Max7456 or something like that. It's on all quadcopter OSDs... so you could buy a minimOSD for $10 and reprogram that to do what you want is you really want a composite video signal for a big screen? or just build/buy a large 7 seg display?

dude, i've been doing this every day for over 10 years and my code is still a giant tangled mess haha even if you plan, it always changes... or you just want to quickly add something to test something which often stays like that forever haha.

ok, few things then Keep in mind i dont really do 'arduino' as such, so not 100% sure how this works, but im gonna assume its pretty similar to 'real world' C coding first, serial stuff, the best way is to add a checksum to the data. To do that, you basically need a way to say "this is a new bunch of data", "here comes the checksum" and "this is the end" and then the code knows when it starts and ends and where to find the checksum. The easiest way to do this (in my opinion) is to use the way GPS NMEA strings do it. They start with a '$', place the checksum after '*' and end with '\r\n' (carriage return and line feed, or simply 'enter') So that means you cant sendthose things as data in the string, but how often do you need to send $ and * right? I like that way as it means your data is totally still readable in a serial console, and you can find online details and calculators to check that your checksum is right. Plus the checksum is a simple XOR of the data i believe, so super easy and fast for the micro... Not 100% reliable, as 2 bits of error could cancel out, as well as some data missing isnt picked up necessarily (ask me how i know) so there is better again, but gets harder. The NMEA one is pretty good most the time though! you can make it better by a) sending small packets, and b) adding a length to it so you know you got everything correctly. It's now no longer a 'standard' method, so calculators no longer work, but will make the code better and still readable A better way is going full big dick swinging binary... so no more human readable data, which is a cunt when you're tyring to debug (but good coders dont need to debug right? as all their shit works first time? ) so you basically need the same way of being able to say "Start" and "End", but you now use binary data (0-255) so you need to pick a number. Standard number is 0x02 for start, and 0x03 for end. But that means you cant send those 2 bytes as data anymore, because the code will think you are starting or ending a packet instead of sending data. Follow? So they use an escape character... 0x10 is standard here again. So what you do is, when you receive 0x10, you just assume that whatever comes next is data, not a command for start or stop or anything. so say you want to send start, 0x01, 0x02, 0x03, End, you send 0x02, 0x01, 0x10, 0x02, 0x10, 0x03, 0x03. Follow still? same goes for sending 0x10, you send 0x10, 0x10. you also want to add a length and CRC to it. So you just make a packet where the first byte after the start is the length, and the last byte before end is the crc. This way you get pretty reliable data through the other end. Granted, if you go and send giant packets, the chances of fucking it up are still quite high... so send 'small' packets. While we're at it, you now also need to tell the code what the data means. I use a command byte for this (or command word if you have lots of shit to send) so my packets look like this [STX] [CMD] [LEN] ...[DATA]... [CRC] [ETX] where STX is start of transmission, CMD is command, LEN is length, Data is a variable length amount of data, CRC is a checksum byte of everything from CMD, LEN and DATA xored together and ETX is end of transmission. Then command usually has a 'set' and a 'get' which i usually assign to the top bit (0x80 for byte and 0x80000 for word) so then i can have a list of commands (in an enum usually) that the code can then use. So e.g. enum commands { CMD_MIN = 1, CMD_MAX, CMD_AVG, CMD_SET = 0x80}; Then you can send CMD_MIN if you want to know what your min value is, opr you can send CMD_MIN | CMD_SET to signal you want top set the min value. I have no idea if you followed all of this... it's a lot of fucking around! and i suck at complaining, especially when i cant post actual code for you to follow haha. So i hope that showed you something at least? maybe? Now, next, Libraries, libraries are great for stand alone things, but you can also tidy up things that arent stand alone. Regardless, libraries still need to work with outside world stuff, they likely never function within themselves and require either inputs or outputs of some description right? actually, fuck it, i wrote a bunch of shit that was impossible to follow, and heres a google result haha. It explains is quite well https://www.arduino.cc/en/Hacking/LibraryTutorial So, now, sharing data say you have a struct or array called data, which has a max, min and avg in it... and you have that in data.c or something. Now you want to change min from usart.c because thats where you got the data from, and you want to read it from the main loop as well to see if you should turn an LED on or something. What you do is you tell the rest of the code you have a variable called data already by putting extern struct data; in the data.h file. Now in the rest of the code, if you include data.h, it tells that copde there is a variable called data and that they can use it if they want. So you can now do stuff like data.min = 10; in your usart.c code, or if (data.avg < 7) digitalWrite(1, HIGH); or whatever. I know that explains it badly, but i hope it gave you enough info to know what to search for on google to get better answers lol

everyone uses those HC-05's and they work. They are shit, but they work Problem with serial is dealing with fuck ups and lost bytes or even just bits... which for a personal project is hardly a problem as it's not a big deal 99% of the time, but if you want to send data that sets up your project which then in turn controls your ECU, you wanna make sure it gets all the data correctly, or else something like "set timing to 38 deg" can turn into "set timing to 110 deg" by the serial timing just being SLIGHTLY off... and serial timing is always slightly off as everyone uses 115200 BAUD, which an arduino cant do with 100% accuracy (it gets plenty close enough as long as it has a crystal, which i think all arduinos have) but yeah, good idea, and do it! I can send you somne ideas on how to packetise data etc if arduino doesnt already have a decent example (which im guessing they probably do) also, roman, this guys is 100% you and you need to watch this!

truthfully, i didnt come because it was raining, there was a cooked meal at my girlfriends house and the last few meets have been shit so had a huge case of the CBFs

im posting here so i dont forget about it and will see what life brings

same boat as @h4nd sorry. Looks like fun, but risky fun haha. Get a rental and try it on that first?

have fun lads!