Discussion of Mark's firmware

Forum for announcements and discussion of beta firmware.
Mark
Site Admin
Posts: 418
Joined: Sun Jul 28, 2013 6:47 am
Location: Brisbane, Australia

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by Mark » Mon Sep 02, 2013 8:43 am

Paul.Allen wrote:First off Mark, I want to say your Firmware is really Awesome! I love how it really does handle the batteries independently. To test it I decided to put in 2 cells that I knew were not the same amount discharged. The file is big so I will email it to you and let you post it if you want. The following are some questions, thoughts and suggestions. Some of them I already know the answer but might as well have it documented.
Some of these questions are already answered in the user guide that I've already posted, but I'll answer them here for completeness:
viewtopic.php?f=3&t=13
Question:
*Is your code timer driven?
Not really. There are some delay() calls in the code - the main one being when reading from the ADC and I'd say that the controller spends most of its time on that delay. The byte code program has delays but they're not implemented by calling the delay() function.
*Do you take any readings during charging, or only when all is quiet?
I take readings both whilst it's charging and also when it's all quiet. The voltage readings whilst charging are only logged to the file and not actually used for determining whether the cell is full (except for a maximum voltage check)
*How many bit resolution are you running the PWM in this version (508)?
10 bits. With a 7.8kHz frequency.
*Is purple for bad battery?
Yep! Generally because the cell has determined a high internal resistance. The actual reason is logged in the data file along with the measured resistance.
*What resolution are you running the ADC at?
Most of the time, I'm running it at 18 bits for voltage and 16 bits for current, but I'm running a lower resolution when doing the internal resistance check. The byte code program can adjust the resolution by modifying the relevant register.
Thoughts:
*Could there be any adverse side effects of having one cell discharge while the other is charging or vice versa? My thought would be reading values under the noise of charging, which if you don’t read them while current is flowing, then this wouldn't be an issues.
I don't think that there should be any problems with running one on discharge whilst the other is charging - I haven't noticed any problems with charging causing noise on the discharge measurements.
Temperature, anything else?
Measuring temperature whilst charging could potentially be a problem on revision 6 & 7 depending on how the temperature sensor is setup - voltage fluctuations caused by the charging circuit could potentially cause noise for temperature sensor reading. With a previous log file that you sent through, there were some strange things going on with the temperature sensor, but I don't think that it was caused by the charging circuitry unless you're also running into a similar problem with running 2 chargers at the same time off a single USB hub as I posted about here:
viewtopic.php?f=3&t=21
Over all I don’t think it is bad, I think it is great, but just trying to think about it.
It's good to think about these sorts of things!
Suggestions:
*Is it possible to add text to the values printed out like I did in mine? Or is there a reason you would like to leave the text out, like for greater ease of reading it into a future plot program or maybe even when we have the LCD?
I think it's easier for processing the data file in Excel and it also reduces the size of the file quite a bit. I've got it outputting a header line so it should be reasonably easy to see what's what when you load it into Excel.
*For Rev 6-7 and on, let’s make the switch positions as I have printed on there, Charge, Discharge and Analyze.
Yep - already on my TODO list - I forgot to add that change in earlier!
When set to charge, I was thinking we could have it hit the batteries with a jolt of current every few minutes or so if they are left in the charger, to counter act the 2mA drain on them (which I still haven’t figured out the exact source but am narrowing it down). Of course the LED’s wouldn't indicate this is happening, it would just take place in the background.
I'll have a think about this. I don't think it's really necessary - even if batteries are left on the charger for 24 hours, that's still only 50 mAh. Would be nice to eliminate it altogether if possible, but it's not the end of the world if we can't.

I've got some ideas for trying to track down where the current is going myself, but I haven't had time to try it yet
*Add the button start for Rev 6-7, not super critical yet but would be nice.
Yep - already on the TODO list as well. I've got an idea for how to make it work in a flexible manner - stay tuned!
*Also, IMO, I think the Red LED when flashing during charging should be on for a shorter amount of time, like maybe 10ms or so. The time between flashes is fine.
That's actually not too easy to do with the way that I've got the code working at the moment, but I'll try to work out a way to do it. There's actually 2 different flashes that occur depending on whether the currently charging cell is running in fast mode or medium/slow mode. Changing the flash for medium/slow mode will be quite easy. The other one not so much. I could quite easily make the flashing for when one is fast charging appear less bright (it already is, but it's not that noticeable) How does that sound?
Really great Mark!!
Thanks for the feedback and suggestions!

jaustinpage
Posts: 5
Joined: Mon Sep 23, 2013 10:59 pm

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by jaustinpage » Fri Sep 27, 2013 1:40 pm

Hi Mark,

On line 4 of State.h, could you change it to read:
#include "EEPROMEx.h"

instead of:
#include "EEPROMex.h"

Helps us linux guys out a ton!

Thanks so much for this awesome firmware!

Mark
Site Admin
Posts: 418
Joined: Sun Jul 28, 2013 6:47 am
Location: Brisbane, Australia

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by Mark » Sat Sep 28, 2013 12:07 am

Done - thanks for letting me know.

I'll include that change in the next version.

JGSchubert
Posts: 25
Joined: Sun Jul 28, 2013 7:59 pm

Re: User guide for Mark's charger code

Post by JGSchubert » Mon Oct 07, 2013 2:09 am

Mark,

I added another #ifdef line to isolate one option of a case statement to get the code to compile with #define Charger_ver5 set, so I can continue to use my original board from Paul. However, it seems to still be waiting for some button input, and the LEDs go white and stay on indefinitely. Any hints as to what else I have to change to get it to work again? (Happy to have it default to the medium button press options or something...)

No need for you to fork your code again - you have enough on your plate - but if you could give me a short list of the areas I should look at that would be great!

Sorry to hear you and your family were sick recently! Hope all is much better now!

Regards,

Geoffrey

Mark
Site Admin
Posts: 418
Joined: Sun Jul 28, 2013 6:47 am
Location: Brisbane, Australia

Re: User guide for Mark's charger code

Post by Mark » Mon Oct 07, 2013 2:17 am

Going from memory, I think that there was a bug in the 512 code preventing it from compiling for the revision 5 board - I've fixed it so the next version should still work for the revision 5 boards.

We're all starting to feel a bit better now - thanks. Hopefully I'll be able to get the next version out for you in the next day or 2.

Paul.Allen
Site Admin
Posts: 98
Joined: Tue Aug 06, 2013 5:33 am
Location: Utah, United States

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by Paul.Allen » Tue Oct 15, 2013 7:07 am

I am having trouble compiling it? anyone else have this problem? In the arduino IDE it says:

C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp: In constructor 'RobotControl::RobotControl()':
C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp:8: error: 'LCD_CS' was not declared in this scope
C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp:8: error: 'DC_LCD' was not declared in this scope
C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp:8: error: 'RST_LCD' was not declared in this scope
C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp: In member function 'void RobotControl::begin()':
C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp:18: error: 'MUXA' was not declared in this scope
C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp:18: error: 'MUXB' was not declared in this scope
C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp:18: error: 'MUXC' was not declared in this scope
C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp:18: error: 'MUXD' was not declared in this scope
C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp:19: error: 'MUX_IN' was not declared in this scope
C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp:22: error: 'BUZZ' was not declared in this scope
C:\Users\Laptop\Desktop\arduino-1.0.5\libraries\Robot_Control\ArduinoRobot.cpp:25: error: 'Serial1' was not declared in this scope

I hope it is not just something simple that will make me feel dumb, but it probably is. : )

Mark
Site Admin
Posts: 418
Joined: Sun Jul 28, 2013 6:47 am
Location: Brisbane, Australia

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by Mark » Tue Oct 15, 2013 7:12 am

That's rather odd - it actually looks very similar to the error that I was getting when trying to compile code with the LCD library included...

A couple of possible solutions:
  1. Maybe try moving the Robot_Control library folder from the libraries folder and see if that makes a difference?
  2. Try updating to the Arduino 1.5.4 Release Candidate IDE and see if that makes a difference?
Also, make sure that you've got the fat16lib library installed correctly!

ukoda
Posts: 22
Joined: Fri Oct 11, 2013 3:28 am

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by ukoda » Tue Oct 15, 2013 7:29 am

Is there any reason you left the output file out? Is it posted somewhere else? I have a problem, I will create a sperate post for elsewhere if needed, but though I should have the latest firmware in case it was a known problem that had already been fixed.

Mark
Site Admin
Posts: 418
Joined: Sun Jul 28, 2013 6:47 am
Location: Brisbane, Australia

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by Mark » Tue Oct 15, 2013 7:36 am

By output file, are you meaning the data.csv file?

That file is automatically created by the code on the SD card if it doesn't already exist.

You're welcome to post in this thread about any problems that you're having with the firmware.

ukoda
Posts: 22
Joined: Fri Oct 11, 2013 3:28 am

Re: Progress on Mark's Firmware (Latest Version Attached)

Post by ukoda » Tue Oct 15, 2013 7:47 am

Sorry, I was being vague because I don't know what tool chain you are using or what output format it uses. With the AVR I'm using GCC under Linux, so I normally work with .hex output files.

I fired up my board for the first time today. After some flashing of lights, that I assume is a power on self test, there was no further LED indication. I set the switches to Analyze medium current, inserted a new battery with a unloaded voltage of about 1.2V, and gave the button a brief press. There was no feedback so I left it a while then checked the SD card. It contains:

Code: Select all

3166,,HW Version 5 FW Version 0.510 Serial # 3
Millis,Channel,Elapsed,Req_Current,Voltage,Act_Current,Power,Capacity,Energy,Temperature,PWM
3334,,Powered On
349775,,Error: 4
350773,,Error: 4
350816,,Error: 4
350849,,Error: 4
350881,,Error: 4
350914,,Error: 4
Looking at the source code that would appear to be "E_ADCReadFailed".

Post Reply