|
Post by Rowan on Aug 26, 2020 13:08:45 GMT
I've spent some more time on the v2 Arduino code and got the time based wheel speed and motor rpm sensing working up to a point. It's quite jittery so could probably do with some more smoothing, and I think it might be reading a bit low, but as I don't have a car to test it on any more it's quite hard to tell. If anybody is in a position to test it on a car and give me some feedback that would be great Code can be downloaded from here: github.com/eChook/eChook-Arduino-Nano/tree/devThere are some additions to the calibration file, so you can't just copy your old one across, you'll need to merge it with the new one.
|
|
|
Post by Rowan on Jul 26, 2020 22:06:59 GMT
Wow, I go on holiday for a few days and the quality of discussion on here skyrockets! I should go on holiday more often Keith's development of the telemetry is excellent, and to be fair, more advanced than anything we had planned with our own site. The eChook live data site needs a beta version of the app to use that a few teams have, however I then started on a completely new version which is fighting for time with too many other projects. It's getting there slowly! As Keith just pointed out, looks like my server has gone down at the moment... I'll check on it when I get home!
|
|
|
Post by Rowan on Jul 24, 2020 10:39:06 GMT
Excellent news! Well done.
The Ah reading is a measure of current over time. If you use the app with the 'lanch' button, it resets the Ah count at race start and lets you know how many ampHours you've used through the race. If you have a good idea of your batteries capacity it can give a good indication of how much power you have left.
|
|
|
Post by Rowan on Jul 20, 2020 11:12:27 GMT
The readings from the arduino are pretty meaningless with the op amp unplugged - it will essentially be reading the voltage between pin 2 on the current connector and ground, but it's good to know that the Arduino is reading in a value, so that side of the system is working as it should. If there is a current reading on the phone screen, the amp hours measured (Ah) will increase as it's just a measure of current over time. Those two wires should give a pretty consistent reading to ground unfortunately - both of around 2.5v. I'm afraid it's looking like the current sensor may have broken somehow. Check that there is continuity from the eChook end of the wires to the pins on the current sensor, and that there is no connection between any of them. I'll send you a PM on here and we can do a final check through before confirming you need a new current sensor... they are generally pretty durable sensors. Generally they're about £20 from Farnell. uk.farnell.com/lem/hais-50-p/current-transducer-50a-pcb
|
|
|
Post by Rowan on Jul 20, 2020 9:45:37 GMT
And not a 12v in sight That's a great step forwards, all the voltages are in safe ranges now! However, the voltages on pins 2 and 3 are still rather high. Is this with the current sensor and op amp plugged in? Pin 2 should always be ~2.5v as this is the reference voltage output by the current sensor, and with no current being drawn, pin 3 should be equal to it. If you disconnect just the wires for pins 2 and 3 and measure the voltage of them without any connection to the eChook board we should be able to narrow down whether the voltages are coming from the current sensor or not. Edit: The current is measured by the voltage difference between pins 2 and 3. As you've measured a difference, the eChook will be reading that in as a current being drawn. I haven't checked the maths, but I'd suspect it would equate to around 116A, so the eChook board and code are probably working. I'm guessing the error may be with the current sensor now unfortunately.
|
|
|
Post by Rowan on Jul 19, 2020 14:06:01 GMT
Hi guys, So yes the 12V is attached when I am doing all of the tests with the multimeter. I have looked over the bottom of the eChook PCB and there does not seem to be any short circuiting. If there was a short where else could it be? And yes I thought I was getting failed readings when I was reading the ip amp when I had it plugged in as I was getting no readings at all on all pins however after trying it unplugged i got accurate readings. I will not have access to the car over the weekend so will continue to investigate on Monday. I would just like to thank you guys for being patient and helping so much don’t know what I’d do without you You're very welcome!
When you're back with the car, before measuring everything as per Keiths diagram I think it's worth working out where that 12v reading is coming from. I'm just worried that the Current sensor won't survive having 12v on one of it's outputs, as it's a 5V device.
Without the current sensor plugged in, power the board up in the car with everything else connected and see if you still have 12v between ground and Pin3 on the Current Connector.
> If you do the 12v must be getting there through the eChook board. Turn off the power, and using the continuity (beep) setting on the multimeter check if there is a connection between the 12v in pin (middle connector on the 3 pin power connector) and pin 3 on the current sensor. I don't really understand how there could be, but I also don't understand how else it could be there.
> If you don't, test again with the current sensor plugged in. If you now get 12v there it must be coming from the harness somehow. Turn everything off again and look for any incorrect connections in the harness. Continuity setting on the multimeter will be useful again.
Op amp wise, is it definitely plugged in in the correct orientation? (Little dot on the end close to the connector) If it still changes the readings (and you're no longer getting 12v to it) then it could be that the op amp has been damaged by something. They are the Microchip MCP6002 op amp, and are not expensive on eBay, or if you have a .edu email adderss you can probably get some for free through microchips excellent sample programme: www.microchip.com/samples/
If you'd like to talk though it over the phone while you're debugging PM me and we can find a time on Monday - Often helps
|
|
|
Post by Rowan on Jul 17, 2020 14:28:20 GMT
Hi Ben,
The worrying reading there for me is 12v on pin 3. Is this with the board hooked up to the car, and do you have the 12v input attached? If so, check for a short circuit between that input and pin 3... If not, I can't think where the 12v would be coming from, but it's not going to be doing the current sensor much good - unplug it until you've got to the bottom of the 12v.
Am I reading it right that op-amp pins 2 and 3 sit at 2.5v, but the pins on the connector don't?
The capacitors are there for noise suppression. As a general rule, the closer they are to the device the better but what you've done sounds absolutely fine.
|
|
|
Post by Rowan on Jul 17, 2020 9:13:25 GMT
In general I really like the Teensy boards - Project wise at the moment pretty much everything I do either runs on a Nano or a Teensy.
Turns out I'm just spreading vicious rumors though - Just flashed the following code as a basic static test and it ran perfectly.
void setup() { pinMode(13, OUTPUT); }
void loop() { static int state = 0; digitalWrite(13, state); //LED state = !state; delay(200); }
I really want to give the ST Nucleo dev boards a go. Cheap, powerful and with proper QC unlike all the only slightly cheaper Chinese boards. I've used MBED with them in the past, and am slowly finding my way around PlatformIO... Arduino is just so ingrained in the hobbyist and rapid prototyping process that it can be hard to escape!
|
|
|
Post by Rowan on Jul 17, 2020 8:22:19 GMT
keduro - Moving the discussion here Good suggestions, thank you. Brake invert and the improved debug mode are very good shouts. The calibration macros are neat too - we had the same setup in Driven years ago, but I'm leaning towards leaving that up to teams to implement I completely agree with you on using static variables over globals where possible as a point of good practice. The reason I haven't is I've had some odd results with them on Arduinos in the past. Most recently with a Teensy 3.2 board where I used them quite extensively, and the code didn't work at all. The fix turned out to be replacing all the static variables with globals and I haven't gone back to properly investigate. I'll see if it will play nice with the nano... I'm also planning on replacing the current array smoothing with an alpha N smoothing. Less intuitive, but far smaller, simpler and quicker in code. Edit - also need to implement the debounce code and get rid of the Bounce2 dependency. (And now I really need to find my bluetooth module that's gone awol and get some more testing done on OMNI! Sorry it's taking me so long!)
|
|
|
Post by Rowan on Jul 17, 2020 8:19:53 GMT
This discussion started in another thread, moving it here so we can stop derailing that one! Previous posts on the subject:
... I took a look at a time based, rather than poll based, calculation for the wheel speed and motor RPM this morning. It turned into quite a big code reorganisation as it really hit me that over time, the changes to that original code have added up and there is a fair bit of redundant code and incorrect comments remaining - sorry about that!! In the years since we originally wrote that code I think my coding style has changed significantly too. So, I have made a new branch of code on github and split the file up into smaller chunks to hopefully make everything easier to find, and more obvious where users can add their own code to the eCHook. It also includes a few improvements that have been found/suggested over time. I have also done a first attempt at the new motor and wheel speed code, and added a toggle to enable it under an 'Experimental' heading in calibration.h. It's currently enabled by default. I'm getting a little ahead of myself sharing it, as I've hardly tested it yet, but hopefully you can see what I'm trying to do. Feel free to give it a shot, just don't be surprised if it doesn't work right now New dev branch of the code is here: github.com/eChook/eChook-Arduino-Nano/tree/dev Any feedback welcome as always You have been busy Rowan, great work. Can I make a small additional request for an update to the dev branch (yeah, I'm too lazy to make a pull request ... ) - how about changing the speed and current smoothing arrays from int to float to avoid discretizing the calculated averages into thirds and quarters respectively. Thanks! Keith Rowan - Rowan, no other optimisations as such to add. A couple of things I have done though are: (a) added additional code in sendData (both overloads) so that when in DEBUG_MODE the identifier and value are printed in plain text rather than being encoded. I've found this useful when debugging eChook code as the output is easily viewed in the serial monitor window in the IDE using a wired connection to the nano in place of bluetooth. Avoids needing to run an additional app to decipher the code (though (as you are aware) I have also put together a windows app which does just that!!) (b) added macros to Calibration.h to allow different configuration parameters for different cars whilst sharing the same code files. I found it easier to remember to change a #define in Calibration.h than to manage multiple calibration files for multiple cars, or managing multiple copies of the code. Here's an abridged version of our current Calibration.h (I've also added a couple of additional calibration values CAL_INVERT_BRAKE and CAL_THROTTLE): /* * This file contains all the values used to calibrate your eChook board. * By seperating these it makes it possible to update to newer code without * having to copy your calibrations across - just make sure you keep this file! * * The values provided by default are for the eChook's team dev board, but each * board is different. These defaults will give readings in the right ballpark, * but for accuracy, see the documentation to calibrate your own board. * * Every variable in this file begins with CAL_ so that it is identifiable in * the main code as being defined in this file. * */
//================================================================================================================================ // // SELECT eChook BOARD -- IMPORTANT !! // // Only ONE of the following BOARD_xxxxxx should be defined at any one time. Other defines should be commented out. // //#define BOARD_ELECTRON #define BOARD_PHOTON // //================================================================================================================================
// Banchory Academy Electron (nee Fifty Shades of Green)
#if defined(BOARD_ELECTRON) // Bluetooth Settings const String CAL_BT_NAME = "eChook"; // Whatever you want to name your car's bluetooth const String CAL_BT_PASSWORD = "1234"; // Changing password from default "1234" tends not to work yet - apologies! // Car Specific Settings const int CAL_WHEEL_MAGNETS = 3; // Number of magnets on wheel const int CAL_MOTOR_MAGNETS = 6; // Number of magnets on motor shaft for hall effect sensor const float CAL_WHEEL_CIRCUMFERENCE = 1.429; // Outer circumference of tyre, in Meters. i.e. the distance travelled in one revolution const bool CAL_INVERT_BRAKE = false; // Invert brake output value - needed if brake input is normally low // Board Specific Calibrations const float CAL_REFERENCE_VOLTAGE = 5; // Voltage seen on the arduino 5V rail const float CAL_BATTERY_TOTAL = (82000.0 + 16000.0) / 16000.0 * 0.993; // which should be 6.125, not 6.15 as provided originally. Final multiplier added to make eChook battery total match Fluke meter reading const float CAL_BATTERY_LOWER = (82000.0 + 16000.0) / 16000.0 * 1.003; // which should be 6.125, not 6.15 as provided originally. Final multiplier added to make eChook battery lower match Fluke meter reading const float CAL_CURRENT = 37.55; // Current Multiplier - See documentation for calibration method // Board and Sensor Specific Calibrations const float CAL_THERM_A = 0.001871300068; // Steinhart-Hart constants - See documentation for calibration method const float CAL_THERM_B = 0.00009436080271; const float CAL_THERM_C = 0.0000007954800125; // Throttle adjustment const float CAL_THROTTLE = 100.0 / 96.5; // Throttle scalar to account for throttle pot being supplied +5 from power controller and not from eChook #endif
// Banchory Academy Photon #if defined(BOARD_PHOTON) // Bluetooth Settings const String CAL_BT_NAME = "___kChook___"; // Whatever you want to name your car's bluetooth const String CAL_BT_PASSWORD = "1234"; // Changing password from default "1234" tends not to work yet - apologies! // Car Specific Settings const int CAL_WHEEL_MAGNETS = 6; // Number of magnets on wheel const int CAL_MOTOR_MAGNETS = 3; // Number of magnets on motor shaft for hall effect sensor const float CAL_WHEEL_CIRCUMFERENCE = 1.181; // Outer circumference of tyre, in Meters. i.e. the distance travelled in one revolution const bool CAL_INVERT_BRAKE = true; // Invert brake output value - needed if brake input is normally low
const float CAL_REFERENCE_VOLTAGE = 5; // Voltage seen on the arduino 5V rail const float CAL_BATTERY_TOTAL = (82000.0 + 16000.0) / 16000.0 * 1.000; // which should be 6.125, not 6.15 as provided originally. Final multiplier added to make eChook battery total match Fluke meter reading const float CAL_BATTERY_LOWER = (82000.0 + 16000.0) / 16000.0 * 1.000; // which should be 6.125, not 6.15 as provided originally. Final multiplier added to make eChook battery lower match Fluke meter reading const float CAL_CURRENT = 37.55; // Current Multiplier - See documentation for calibration method
// Board and Sensor Specific Calibrations const float CAL_THERM_A = 0.001871300068; // Steinhart-Hart constants - See documentation for calibration method const float CAL_THERM_B = 0.00009436080271; const float CAL_THERM_C = 0.0000007954800125; // Throttle adjustment const float CAL_THROTTLE = 100.0 / 96.5; // Throttle scalar to account for throttle pot being supplied +5 from power controller and not from eChook
#endif
Ben ... I'll post a separate reply re your current sensor testing as we're probably breaking all forum etiquette by discussing multiple topics in a single reply let alone within a single thread! -- Keith. ... In the years since we originally wrote that code I think my coding style has changed significantly too. So, I have made a new branch of code on github and split the file up into smaller chunks to hopefully make everything easier to find, and more obvious where users can add their own code to the eCHook. It also includes a few improvements that have been found/suggested over time. ... Rowan ... You asked for feedback, so here we go . Let me preface what I'm going to spout forth below by saying that this is very much my coding style and it is personal. Not saying its right, not saying other styles are wrong, we all evolve our styles over time. I've worked on software development projects where there have been defined coding standards, some were good, some not so good, but I think every programmer on the development teams managed to fault the coding standards where they didn't conform with their own style. So please (please) just take the following as reflecting my style and preferences, and of course, feel free to disregard entirely. One of my own preferences is to keep variable declarations as local as possible to their use. I'm not against global variables being used where they need to be referenced in multiple functions. But if a variable is only used in a single function then I would declare that variable in the function. But isn't this true in the eChook code I hear you cry? Yes for most variables, but as a specific example consider the global variable: unsigned long lastShortDataSendTime = 0; This is intialised in 'setup' (master) / in 'eChookSetup' (dev) and is then only used within 'loop' (master) / in 'eChookRoutinesUpdate' (dev). My preference would be to define 'lastShortDataSendTime' in 'loop' (master) / in 'eChookRoutinesUpdate' (dev) as follows: static unsigned long lastShortDataSendTime = millis(); The 'static' ensures the variable's value is preserved between calls, and the initialisation only happens on the first time through. This makes the declaration much closer to its use and only within the scope of the function using it. The same approach could be taken for a number of variables currently declared globally, including (but not limited to): lastWheelSpeedPollTime - only used in 'readWheelSpeed' lastMotorSpeedPollTime - only used in 'readMotorRPM' currentSmoothingArray - only used in 'readCurrent' speedSmoothingArray - only used in 'readWheelSpeed'
How much do I care about this .... in reality ... not enough to have made me change this in the version of the eChook code that we use here .
Just a thought .................. Keith
|
|
|
Post by Rowan on Jul 17, 2020 7:58:16 GMT
So i have just took out an old current sensor that was supplied by greenpower we just had a spare laying around to see if that was the problem, we tried it and nothing happened again. we did flip the sensor round in case that was the problem however this only gave us a reading of 2 max and was limited with the results that it was giving us. ie it was either 0 or 2. also as i am new to this coding, what is the easiest way to save new code, i only ask because when i go to verify some code it gives some errors that it is taking information from other folders around it. im not sure if this is what is happening but i have a few folders with multiple Arduino apps open atm. Ben What is the other sensor you've tried? The differential amplifier on the eChook board is set up for the reference and signal voltage from the HAIS 50-p so might not work so well for others - depending on their output. Also where is that reading being taken from? Multimeter or eChook, what units? In addition to Keith's suggestions, with the eChook sensor, I'd verify that you have: > 5v and GND at the sensor > circa 2.5v on the sensor at both sense and reference pins > continuity between the sense and reference outputs and pins 2 and 3 on the op-amp. > Resistance of 47k ohm between pin 1 on the op amp and Pin A2 on the arduino. For the Arduino code, you should just be able to place the code in different folders. Due to Arduino peculiarities the eChookCode.ino file always has to be in a folder of the same name, so it should work laying them out as, for example: .../Code/MyeChookCode/eChookCode/eChookCode.ino .../Code/StockeChookCode/eChookCode/eChookCode.ino The IDE does look in the library folders for the Bounce library when compiling, but that's normal. Hope that helps!
|
|
|
Post by Rowan on Jul 16, 2020 13:54:30 GMT
For the speed reading, it sounds like the Arduino is definitely getting an input. Next test I'd do is flash the Arduino with a fresh copy of the code from github, just to make sure that it's not a change you've made to the code that's stopping it reading. Current sensor wise, pins 2 and 3 should be sitting around 2.5v. Does the current sensor definitely have 5V going to it? keduro - good shout, done. Any other optimisations you've found while I'm at it? I've recently had to dig into the Arduino compiling system for a different project and realised that it was far easier than I'd thought to split the program across multiple files. It makes it far easier to find things I think.
|
|
|
Post by Rowan on Jul 16, 2020 11:13:10 GMT
I am not sure if the app is communicating with the downloads on within the phone as the downloads folder is empty. When i am running the car there is a tick next the the save icon in the top right of the screen. Do i manually need to 'share logged data' with an external source to to see a history of the data or should all of this be automatic? Also when i start and stop the connection, like it says in the documents that it should, it says the exact amount of data that it has stored in the top left of the screen. Though me it seems like there is data being stored somewhere i just don't know where to find it. thanks, Ben We've seen simmilar issues lately with the log file, with other apps as well as ours. It is there, as the file size would show 0 kb if it couldn't find it, however Android seems to be hiding it, or the file manager isn't showing .csv files maybe?? Does it show on windows file explorer if you plug the phone in? If you can't find it on your phone for any reason, going through the share menu should allow you to email/upload/etc it. Regarding current and speed, that seems like the signal either isn't getting to the nano in the first place, or you might have inadvertently disabled the code that reads it in? I took a look at a time based, rather than poll based, calculation for the wheel speed and motor RPM this morning. It turned into quite a big code reorganisation as it really hit me that over time, the changes to that original code have added up and there is a fair bit of redundant code and incorrect comments remaining - sorry about that!! In the years since we originally wrote that code I think my coding style has changed significantly too. So, I have made a new branch of code on github and split the file up into smaller chunks to hopefully make everything easier to find, and more obvious where users can add their own code to the eCHook. It also includes a few improvements that have been found/suggested over time. I have also done a first attempt at the new motor and wheel speed code, and added a toggle to enable it under an 'Experimental' heading in calibration.h. It's currently enabled by default. I'm getting a little ahead of myself sharing it, as I've hardly tested it yet, but hopefully you can see what I'm trying to do. Feel free to give it a shot, just don't be surprised if it doesn't work right now New dev branch of the code is here: github.com/eChook/eChook-Arduino-Nano/tree/dev Any feedback welcome as always
|
|
|
Post by Rowan on Jul 16, 2020 8:18:48 GMT
Nothing misrepresented there Keith, I'd missed we were still doing it all as integer! That will make a significant improvement.
Changing the short transmit interval will double the resolution of the speed and RPM signals, but it also halves the frequency of all logging which will show as a lot of repeated values in the .csv logfiles. 0.5 seconds is probably still more than fast enough for most logging purposes though!
Are speed and current showing up in the app?
|
|
|
Post by Rowan on Jul 15, 2020 12:40:57 GMT
It will be a bit more involved than editing values in the current code I'm afraid. The current code is a compromise between update interval, resolution, and simplicity. You can alter the timings (defined by where it's called in loop()) to sacrifice the update interval for improved resolution. You'd need to add a second counter to call the routine less regularly.
Alternatively you can alter the way the interrupts work. Create a couple of new global variables to hold the last seen pulse time, and the latest pulse interval, then every interrupt you can calculate the current millis() - 'last seen time' to give your latest pulse interval, and reset the last seen time to the current millis(). You can now alter the readRPM() function to convert the latest global pulse interval value (i.e. the number of milliseconds that it's taken for one revolution of the motor shaft, assuming one magnet on the motor shaft) into an rpm value. If milliseconds don't give you an adequate resolution you can use the micros() function to measure in microseconds.
There is a note of caution with this approach - the millis()/micros() value doesn't update while the interrupt code is running, so it's generally considered bad practice to use it within an interrupt, however as you only really care about the time at the moment the interrupt is triggered it actually works in your favour here.
I appreciate that's a bit of a deep dive for someone new to coding! If I find some time I'll see if I can get an example up and running.
|
|