Ok...thanks Rowan.....but I'm 12,000 miles from my PC at the moment, so that will have to wait a couple more weeks☹️.. But I didn't realise that serial to bluetooth was encoded in a different way to 'bog standard' serial (technical term).. I thought 'serial' was 'serial', and that it was just the signal levels(like TTL and RS232) that varied...so I can take some time to research a little more into BT...J
There's no difference in the signal level transmission, but instead of just sending the data as ascii characters in a CSV type format, each value is broken down into an identifier and value and packed into a 5 byte packet. This keeps a very low data rate (in hindsight, far lower than we needed to get it), but has it's drawbacks - such as the data isn't human readable with a standard serial interpreter.
...so just thinking ahead... Going along with your suggestion of 'squirting' out a .csv file....and progressing with caution at this stage....As I only need to transmit, there is a library available for 'Software Serial, Transmit Only' on Github...Can I assume it's ok to 'include' that, and output to (say) Pin 12 (D9)?
....ok...but was just thinking about tying up as few pins as poss...but as the pins are available, I guess it would make more sense to use a well tried and tested library...at least in the first instance.. Thanks again..
Hi Rowan...Hope this finds you and yours well!! Back at the sharp end now...Re: the ramp routine you kindly wrote for me: I wonder if you would have any theory on the following... We (Pods..Chipping Sodbury School) now have the echook completed..When checking the board with the echook sketch, plus the throttle ramp, I noticed that (almost) every time the throttle is opened, for a fraction of a second, just as the PWM is reaching 100%, the output drops to zero, before returning to 100%....It is only for a fraction of a second.(.doing a video frame count, I reckon it's about a fifth of a second)...I first noticed it with the onboard PWM LED.. I reloaded the original stand alone ramp sketch you sent me, and the glitch is there also..I just hadn't noticed before.. I think we can get away with the Mark/Space jitter, but the drop to zero would definitely be noticed in the car... I have a few seconds of 'scope video of the glitch if of any use... Sorry to be a pain, but any help would be appreciated.. Thank you. John
....Just an afterthought...The Nano in the echook is not the one I did the original test with, so I wondered if it could be a problem with the new Nano...but I fired up my original nano..and the problem is there also..J
Last Edit: Mar 24, 2020 19:17:10 GMT by littlejo44
Hi Rowan.. Hope this finds you and yours well in these troubled times.. Despite the lockdown, or maybe, because of it, things have moved on faster than I expected with our new car, and we are nearing the point when the car and the electronics will need to unite..so I'm thinking I need to ignore the slight glitch with the ramp routine and concentrate on attempting to 'squirt' the sensor data to our radio telemetry link.. But...In the interest of time, (and of getting it to work!), I would really appreciate your help here.... Many hours of 'Googling' and reading have proved to my 76 year old brain that my earlier euphoria and confidence at being able to 'make an led flash', were a little premature, and that there is much more to this than I was expecting😩 I should have spent more time learning about bits, bytes, syntax and terminology in general before entering the world of C++! I'm sure, by now, you want me to get to the point! I just need to send the basic Sensor Data, in ASCII format, before any average calculations, via 'SerialSoftware', to our existing telemetry.. I'm thinking that any calibration or calcs can be carried out on the receiving pc.. But...my research has shown that there are (possibly) many ways of doing this and I really have no idea which way to go that's going to give me the most chance of success..Would it be better to send a lot of 'serial write' lines sequentially, or (as we've done with out previous car), combine all the sensor readings into one string?.. What I'm really asking is...could you possibly give me a line of code as a starting point for testing..The Serial Software library is installed and included in the sketch..No handshake is required.. As always, your help would (even more than usually) be appreciated.. John.. Bristol. Happy Easter!!
Hi John, its Keith from the Banchory Academy Greenpower team here. We've done a lot with the eChook and thought I might be able to help you out a bit here - just as Rowan has helped me in the past :-)
I have added a little code to the stock eChookNano code to output a CSV formatted string of values that hopefully is something like you are looking for. This is the output I'm seeing every 3s on my monitor:
I have simply written the data to Serial - you can replace Serial in the last block by SoftwareSerial if you are using that. Alternatively, if you decide to only send data to your existing transmitter and not use the bluetooth connection to the eChook companion app (though I can very much recommend its use!), then you could just use Serial - but then you'll need to comment out the 5 Serial.write lines at the end of the two sendData functions defined towards the end of the code, just before the code to configure the HC-05.
Hi Keith...I (obviously) haven't had a chance yet to properly read your post, but just wanted to get back asap to say 'thank you' for taking the time to try and help an 'old timer' who's more at home with 'valves and variable capacitors' than he is with bits and bytes😩..I'm guessing you can sense my frustration! Thank you so much, and I'll have a close look later.. Kind regards.. John.. Bristol..
One old timer to another :-). In my youth I used to fix up old valve sets that were being discarded in favour of the new fangled transistor radios. Then I got a Philips electronics set one Christmas. BC108s have a lot to answer for :-). -- Keith
John, hi again, just to be absolutely clear, in the post above where I said use SoftwareSerial I should have said use the SoftwareSerial object you declared. So if you declared say SoftwareSerial mySerial(2,3); then you would use mySerial.print and mySerial.write. -- Keith