Ned

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!

that seat looks REAL comfortable for endurance rides

im out sorry guys, i need to save my holidays and money for other shit, sorry

should we remind that @Snoozin character?