Cycle Analyst V3 preview and first beta release

Hi Pendragon,

The CAv3 is a bit daunting with all the new features and settings. The most obvious thing that comes to mind is that you may have forgotten to break the Tho out of the DP into the throttle connection to the controller.

Did you read through Teklektik's manual? Very nice description how you should connect it, including all first settings.
 
Okay, so attached is a Beta21 firmware file that has 3 main changes:

#1) Current / Power Throttle Kick: The issue (introduced only in Beta20) that was causing an unpleasant kick at the start of applying throttle in current or power throttle modes has been fixed.

#2) Proportional Torque PAS in Watts: The proportional torque assistance has been changed from a current control (mA/Nm) to a power control (watts/Nm), so that if you change battery voltages or have a pack that drops in voltage significantly over the course of discharge (eg LiPo), the power assistance factor stays the same.
Trq Assist Watts.jpg

#3) Bootloader Mode from Main Code: If the CA receives the character 0x55 (=ascii "U") at any point during normal operation, it will display "...PC Connection" and then jump to the bootloader code section where any of the eeprom settings can be changed. This also means that once you have the B21 firmware installed, you no longer need to power cycle the CA in order to reflash it with the bootloader software, which is a bit it more convenient. And makes it easier to do firmware upgrades via a serial->bluetooth connection as well.
View attachment 1
 

Attachments

  • CA3_B21_NoCal.zip
    46.6 KB · Views: 171
Eascen said:
I figured I would start with attempting to read some data first, before I go attempting to write things. Following the guide above, I've got it into bootloader mode, and have the following being sent:

Hey Eascen, nice work tackling that one quickly!

though I requested an LEN of 0x01, I'm receiving 18 response bytes.

Indeed, it turns out that in the interest of trimming the bootloader size it was tweaked to only return full rows (8 bytes) of eeprom data, so if you request a length of say 2 bytes, it will respond with the first 2 bytes correctly and then another 6 bytes of potential garbage. If you request say 16 bytes, it will reply with just the last 8 bytes of that request. Effectively there's an 8 byte buffer that the eeprom reads get moved into, and the buffer is always sent in full.

For writing new values to eeprom, the length field is handled properly up to 8 bytes.

Mem3:
Code:
0, 5, 4, 0, 247, 128, 127, 20, 251??, 64, 0, 254, 48, 255, 0, 255, 64, 191, 132 (again, csum?), 0x04.
Mem4: No response
Mem5: No response

And this is where the byte stuffing comes in. In the AppNote, microchip used 0x55 as the start of the packet, and 0x04 as the end of packet (the first 0x55 is the sync bit for auto-baud detection). As a result, if 0x04 or 0x55 are ever in a different part of the packet, either as part of the data, address, or command, then they must be preceded by the Data Link Escape (DLE) character 0x05. Similarly, if 0x05 needs to be sent, it also needs to be preceeded by a 0x05. In calculating the checksum, all instances of the 0x05 as DLE are ignored, whereas instances of 0x05 as data/address/command are counted.

It's a bit unfortunate, but the two commands relevant here, RD_EEDATA and WR_EEDATA, are commands 04 and 05, and so both need to be preceeded by the 0x05 escape character.

If you use the normal bootloader program, it creates a log file "serial_communication_record.txt" which you can open up to see all the back and forth between the computer and CA, and can copy and paste commands from there while sorting out and verifying stuff. Notice the last command:
Code:
0x55 0x55 0x00 0x00 0x00 0x04
which causes the CA to exit the bootloader and return to normal operation.


If I'm on the proper track and value 2 (index 1) is actually the value I'm looking for, I'll call it a day and wait for the mapping; though it makes Mem3 look off, If you have a few basic mappings I can use for testing, I can likely get quite a bit further tomorrow :).

So that took a way longer time to organize and compile, but the full memory table for the B21 code is in the attached spreadsheet. Hopefully it should be pretty clear. You can totally break the code by putting values in here that are outside of the expected bounds. So for instance, programming in a Preset of 5 (outside of the 0,1 or 2 which are allowed) would cause all kinds of crazy behavior. That goes with every setting that is part of finite set, since I'm not doing any bounds checking on eeprom arrays.

You'll notice too that there are a small number of settings which aren't settable via the setup menu. Some of them are dependencies (like the DGainSpan) while others might be useful for people doing more OEM type customizations. For instance, the 13 bytes of InnrSetupMask lets you control whether individual items show up in the setup menu or not. So if you don't want the speed limit to be changeable, you'd note that the speed limits are the 5th setup menu, and max speed is the first option, so if you set the 5th byte of InnrSetupMask to b'01111111', then it would skip over the MaxSpeed setting and jump right to the next item "Strt Speed". On a similar note, if you want to be able to change your speed limit but only up to a certain maximum, then that hard coded max can be set at address D8 MaxSpeedADR, and any value that a user puts in via the setup menu will be clamped to this.

Thanks again for supporting this, and I apologize for my lack of low level programming skills, most of my work is done in higher level languages.

I'd say you've done quite well. Let me know if there is anything more I can help with.

-Justin
 

Attachments

  • B21 Eeprom Memory Table.xls
    68 KB · Views: 284
Love the progress, although "PC Connection" wouldn't always be an accurate description if it's connected to a smart phone.
I can't think of a better phrase to use that would be more general though. "External Config Mode" maybe?

Justin, for adding a timestamp to the datalog file from Windows or Android, do you want the system time or a timestamp of a counter going up from 00:00.00 or both?
 
Bartimaeus said:
Love the progress, although "PC Connection" wouldn't always be an accurate description if it's connected to a smart phone.
I can't think of a better phrase to use that would be more general though. "External Config Mode" maybe?

While it may not be accurate, I think most people would understand what is going on. "PC Connection" would be difficult to be confused with something else. "Configuration Mode" sounds like you are in the setup menu.
 
ashwright said:
Bartimaeus said:
Love the progress, although "PC Connection" wouldn't always be an accurate description if it's connected to a smart phone.
I can't think of a better phrase to use that would be more general though. "External Config Mode" maybe?

While it may not be accurate, I think most people would understand what is going on. "PC Connection" would be difficult to be confused with something else. "Configuration Mode" sounds like you are in the setup menu.

I can see how that could be misleading. I would consider it to be the same basic thing as the setup menu, since you're sending commands to the CA to set values for the settings. The only difference is that you're sending your values over the serial connection and through a different user interface than the main screen.
 
I just started experiencing the new cycle analyst. I plan on putting them on my high end electric bikes in 2013.

I must say the CA is absoultely awesome!!

Excellent work ebikes.ca and Grin Technologies!!

:D
 
Bartimaeus said:
ashwright said:
Bartimaeus said:
Love the progress, although "PC Connection" wouldn't always be an accurate description if it's connected to a smart phone.
I can't think of a better phrase to use that would be more general though. "External Config Mode" maybe?
While it may not be accurate, I think most people would understand what is going on. "PC Connection" would be difficult to be confused with something else. "Configuration Mode" sounds like you are in the setup menu.
I can see how that could be misleading. I would consider it to be the same basic thing as the setup menu, since you're sending commands to the CA to set values for the settings. The only difference is that you're sending your values over the serial connection and through a different user interface than the main screen.
As a rule of thumb, it's not a good idea to name such things by use - rather, they should be named by intrinsic functionality. In this case, "External Config Mode" is the former and clearly inaccurate if this CA mode is used by other applications as a bootloader or to access (non-)EEPROM memory for other purposes. The term "PC Connection" may be benignly flawed because of the fixed remote machine type designation, but it remains consistently meaningful in the context of any use case including the specific (remote config) application at hand.
 
Bartimaeus said:
Love the progress, although "PC Connection" wouldn't always be an accurate description if it's connected to a smart phone.

Yeah, that was going through my mind too but I couldn't come up with a phrase 16 characters or less that was more clear. The close contender was "..remote connect" , but I'm all ears to other suggestions. I would suggest though that a smart phone is the new Personal Computer, and so the meaning of PC in this context isn't confusing.

Justin, for adding a timestamp to the datalog file from Windows or Android, do you want the system time or a timestamp of a counter going up from 00:00.00 or both?

Both is a bit unnecessary but a system time would at least give new info that a counter that starts at 0:00:00 wouldn't give. The analogger doesn't do any time stamping except for on the file name itself, which includes the time at the begining of the data acquisition, and then any software just calculates the time of each data point based on the line number and CA data rate (1Hz or 5Hz). But admittedly it would have been more standard practice to have a relative time stamp included at the start of each row.

-Justin
 
lester12483 said:
I just started experiencing the new cycle analyst. I plan on putting them on my high end electric bikes in 2013.
I must say the CA is absoultely awesome!!
Excellent work ebikes.ca and Grin Technologies!!
:D

Hey Lester and good to hear. A lot of the things we are working on now are going to better help OEM types who want to tweak the functionality of the CA to match their bike and user needs and then hide any extraneous stuff that isn't relevant or that you don't want changed. So even though all the settings and options can seem confusing now, in principle it could be dialed in to be simpler and more intuitive for a new user than the V2 devices. Stay tuned for a basic software package that would let you customize the interface in this way, and in the meantime let us know if you run into any issues or questions.

-Justin
 
Regarding name for 'PC Connection'

External Device Port. 16 char limit so
Ext. Device Port
 
I'll vote for "Configuration Mode", but I care little of what it says, functionality is all the same. I have values reading to 180 (few timing issues with threading to handle tomorrow (not sure if I know how to power this at work but at least when I get back) I should have the full read of values to which I can start converting.

Justin, out of curiosity when the CA shuts off it sends out a CA## message, which... earleir when I was trying to keep track of state I did note also plagued the updater. When you power down the CA to flash it, it think's it has hit startup and then subsequently failed. Now that this mode can be entered from any point, I suppose it's moot.

Before I get too much farther on this, does anyone here have an interest in creating a reusable memory mapping piece of code for this while it goes along? I'll likely start hardcoded, but that doesn't bode well for multiple firmwares.
 
Regarding Street/ Trail mode that was first mentioned back before page 16 of this thread.
Sorry if this has already been covered, just started re-reading the whole thread, but only got as far as pg 16 last night.

First... Did it get implemented? Or was it further built upon .. I believe VALET / restricted user mode was also mentioned If not, second question is irrelevant

Second: does each mode store settings for every parameter, or was it implemented to just control a limited number of parameters, like Power. So for instance, one mode would have PAS / THUN sensor monitoring, mild throttle mapping,etc and the second mode set to ignore every other input except throttle, e-brake and temp sensor with unlimited power and aggressive throttle response
So each mode is effectively a completely different set of settings?
 
NeilP said:
Regarding Street/ Trail mode that was first mentioned back before page 16 of this thread.
First... Did it get implemented?
Yes - as of V3B20 there are three available 'Presets' and three available battery pack configurations :D. These can be selected either by going into Setup and jiggling a couple of parameters or from outside Setup by holding down a console button and repeatedly pushing the other button to cycle through the available options - holding the left or right button determines if selection is for batteries or presets.

NeilP said:
Second: does each mode store settings for every parameter, or was it implemented to just control a limited number of parameters, like Power. So for instance, one mode would have PAS / THUN sensor monitoring, mild throttle mapping,etc and the second mode set to ignore every other input except throttle, e-brake and temp sensor with unlimited power and aggressive throttle response so each mode is effectively a completely different set of settings?
Not all parameters may be set uniquely for each preset but Justin has made a select set preset-specific to allow the multi-mode operation you describe. The common or global settings generally are those that reflect some underlying hardware characteristic that could not reasonably change from preset to preset (e.g. tire circumference or max throttle input voltage). Please have a look at the available config settings for V3B20 here - the doc indicates whether a Setup parameter is global or preset/battery-specific.
 
teklektik said:
from outside Setup by holding down a console button and repeatedly pushing the other button to cycle through the available options - holding the left or right button determines if selection is for batteries or presets.

Ah great..that then is as described in the initial ideas phase.. I am slowly going to go through and digest all 54 pages of this thread..but only up to 16 so far.

Thanks for the doc link
 
Eascen said:
I'll vote for "Configuration Mode", but I care little of what it says, functionality is all the same.
Agree..not a major issue.
Maybe in light of your suggestion
"Ext. Config Port" rather than "mode"
 
I believe I have reached the first measure of success, reading (almost) all the memory values into an appropriate array. I then used Justin's Excel file to build a memory map to load the bytes into usable values, which then left me with this:
ca_readvalues.png


I've committed the initial, not really tested other than on my desk, that does nothing but read to: https://github.com/Eascen/CycleAnalyst

My question(s) now: There are 115 values, and while I have a CA, I don't actually use mine (yet) so what I'd like to do is compile from the beta users, what the most important editable values for a UI would be to get this started into something usable. I could always dump this to a plain UI and let users change values, but with no error correction or value checking it's easy to hose things up... not to mention the conversions are a bit off, just from straight values. Not terribly... usable.
 
Since you're working on a protocol for data input into the CA anyway, how about this?

I got an idea when I saw this thread's post:
http://www.endless-sphere.com/forums/viewtopic.php?p=669709#p669709
where any BMS (or other device that can read cell voltages) could use a serial protocol to periodically send the voltages both pack and per-cell to the CA for display, if the CA is set to that mode.

If it is in the "cell-level" display mode, the bottom line turns into a bargraph, with the top line still having two other numeric values (for myself I would choose speed and either realtime amps or realtime watts, depending on what I was testing, occasionally realtime Ah, and possibly very occasionally other data).

The bargraph could display up to five cells per "character", with up to seven levels per cell, with the bottom dot representing 0V and top dot representing full-scale for whatever cell type it is. The BMS would send the scaling info first in each "frame" of data (containing the values for all cell groups in the pack), then the full pack voltage, then the most negative cell thru all the middle cells up thru the most positive cell.

If there are enough fewer cell groups than 1/2 of the total number of vertical bars possible with the screen width, then each character can be used for only two cells, with the center column of each character always left blank, and only the two leftmost and rightmost columns of a character used for the cell bargraphs, so it is even more apparent that they are each separate cell.

It could also be done that way for even higher cell counts, using both rows of the screen for bargraphs, but for myself I need the speed data onscreen all the time regardless (well, most of the time).


The update speed would probably be pretty limited, so it might not be useful for watchng realtime sag during short power bursts, but it would be helpful in pack diagnostics on longer hauls with high drains, or during charging.

Of course, until someone then develops, makes, and sells the device that can monitor the pack's cells (doesnt' ahve to do anything else) and send that data via this protocol to the CA, it's not a useful function. But if the ability was there, I would guess that someone would make the other device soon enough. ;) I periodically see requests for a single device to do what the CA does plus cell-level readouts in some easier-to-interpret manner than a list of voltages, so....


I recommend using the bottom dot for 0V rather than simply whatever the cell-level LVC should be, because it can also help diagnose a pack with broken balance wires (assuming the BMS isn't able to detect that and cut off discharge or charge, apparently a common enough issue).


I wouldn't expect it to be implemented anytime soon, if ever, but it would enable a small part of what the OP of the thread I linked to appears to want--a way to have cell-level voltages affect the operation of the bike. This might allow the CA to become a kind of BMS, moreso than it already can be (at pack level), by letting it monitor cell-level activity and reduce power demand to reduce voltage sag on dangerously low cells, and cutoff discharge entirely once a cell is too low.

The actual idea as-posted couldn't, but it's easy enough to extend the idea so that a cell-level LVC can exist in the CA, and it checks the data in the stream against that and anything below that LVC results in whatever action is programmed into it by the user. (or picked from the options).
 
Just got my new v3 today, and with the help of Teklektik's well thought out set-up post and jumping the green wire to the controller throttle connector I'm up and running. So far it's wonderful..the throttle has settled down beautifully with minimal help from me (just the regular set-up stuff).
I just wanted to say thank you to all the folks that have placed very useful posts around the thread-y'all are, collectively, the bomb.
On Sunday (my day off) the tweaking shall begin :)
 
Im trying to set up the V3 with a castle controller and a magura-like resistor throttle.

While test riding throttle is cutting off at about half twist. With testing the throttle is cutting off at 1.8 volts, even though I have it in the set throttle in set for maximum of 4.99 volts. Fault is set to 4.99 as well.


Also it is doing the same thing but not as severe with hall sensor throttle.

Any help anyone could offer would be appreciated.
 
Green Machine said:
Im trying to set up the V3 with a castle controller and a magura-like resistor throttle.

While test riding throttle is cutting off at about half twist. With testing the throttle is cutting off at 1.8 volts, even though I have it in the set throttle in set for maximum of 4.99 volts. Fault is set to 4.99 as well.

Also it is doing the same thing but not as severe with hall sensor throttle.
Please try following the setup instructions in this post - it will also refer you to a workaround to get resistive throttles working with the V3.

I'm unfamiliar with castle controllers or any special requirements for throttles that may exist there, but assuming the controller throttle input is in the 0-5v range, the post will get the throttle output and controller input ranges matched, etc.
 
Green Machine said:
Im trying to set up the V3 with a castle controller and a magura-like resistor throttle.

While test riding throttle is cutting off at about half twist. With testing the throttle is cutting off at 1.8 volts, even though I have it in the set throttle in set for maximum of 4.99 volts. Fault is set to 4.99 as well.


Also it is doing the same thing but not as severe with hall sensor throttle.

Any help anyone could offer would be appreciated.

I'm using the CAv3 with a Castle HV-160 ice2. This post might be helpful. The quoted e-mail conversation in that post should be read from the bottom - up. Hope it helps!
 
Back
Top