Cycle Analyst V3 preview and first beta release

justin_le said:
Hey Adrian, nice work on completing the tidy Brainbox too btw! It's no small feat to go from a concept/prototype into a first small scale production run like that,,, i would know ;)
Thanks. If CA v3 was available back then, I doubt I would have bothered. But still very glad I did it.

IF the throttle output of the CA is mapped properly and the controller takes the throttle signal as a direct control of the PWM duty cycle, then the CA should be able to estimate the motor current from
Motor Current ~= Battery Current / (Act Throttle Output / Full Throttle Output)
I like it.

The actual footprint of the small LCD PCB is just 80mm x 36mm, and we made sure that the V3 CA boards would fit within this boundary. So in principle you could make a fairly small box around it. The old hammond enclosures we used to machine for the application were 100mm x 50mm.
Interesting. A tight enclosure around the smaller 16x2 would be pretty neat, and the new v3 CA hardware has everything an ebike could want... Hmmm that has got me thinking.

The current limit automatically starts to scale linearly downwards when you hit the thresh temp, until it reaches 0 amps when you reach MaxTemp. I don't think anything more than this is really needed for effective overtemp protection, but if you have other ideas I'd be curious.
Sounds perfect to me.

Good luck with your ride. Stay safe.

- Adrian

P.S. Will Grin Tech be at Interbike? I was thinking of dropping by.
 
PLEASE add the flasher function for instance I am deaf or someone is also deaf dependent on light warning such light or LED flasher technology. Maybe flashing the LCD display such SoC act like warning LVC is near.

justin_le said:
Doctorbass said:
Did you ever thought about including a programmable BEEP piezo alarm option we could setup for ex low SOC alarm etc?

I think we need to be careful making sound noises. Certainly my tendency is to want to smash electronic devices that beep at me, so it's unlikely that the idea of a piezo buzzer would make it into the design!

However, I think we could do a compromise Stéphane where parts of the display would then flash when a hard limit is hit? so for instance if LVC is reached then the battery indicator blinks, if overtemp is reached then the temperature readout flashes etc. That would also be useful to tell people what is going on when the CA starts to throttle back the power output, and it shouldn't be too difficult to implement.
 
Just wondering if there will be a firmware upgrade for the current Analogger to dump other (new) input data as well - minimally Temp data but the Aux Pot would be nice as well since it would reveal (usually) a changable operator control setting (limiting of one sort or another).

A handy feature for the Analogger might also be to dump a short ascii file on startup named CAsetup_XXXX where XXXX is the same as the CAlog_XXXX file. The file would just contain a dump of the setup and advanced setup for the CA - one parm per line in 'name = value' format. Tweaking settings and recording data for test runs would then leave each data log with a corresponding file of the exact setup in use at the time. Although not always useful, the files would be of inconsequential size and easily deleted en mass if unwanted.
 
teklektik said:
Just wondering if there will be a firmware upgrade for the current Analogger to dump other (new) input data as well - minimally Temp data but the Aux Pot would be nice as well since it would reveal (usually) a changable operator control setting (limiting of one sort or another).

No need to update the analogger, since it already records to the SD card exactly the text that is output by the CA (or in fact, any other device with a 9600 baud ascii stream). At present, in addition to streaming the Volts, Amps, Speed, Distance, and Ah, the V3 also adds to the mix:

Throttle Input Voltage
Throttle Output Voltage
Aux Voltage
Temperature
Pedal Power
Pedal Cadence

A handy feature for the Analogger might also be to dump a short ascii file on startup named CAsetup_XXXX where XXXX is the same as the CAlog_XXXX file. The file would just contain a dump of the setup and advanced setup for the CA - one parm per line in 'name = value' format. Tweaking settings and recording data for test runs would then leave each data log with a corresponding file of the exact setup in use at the time. Although not always useful, the files would be of inconsequential size and easily deleted en mass if unwanted.

That's a great idea for sure. It wouldn't be the Analogger doing this but I could have a small header that the CA itself outputs during the bootup sequence. At the moment it just sends a line that says "V, A, Ah, Sp.. "etc, but it could instead be a header block with a more detailed breakdown of the parameter settings.

-Justin
 
dodjob said:
Really nice improvements there! :)
In Europe we have the legal possibility to have a "push/start-help" 'til 6Km/h (without the PAS signal) after this speed a PAS signal is needed to reach "full" speed. Any infos If this could be inplemented or if it eventually already the case? ^^

Yes, at present I have almost the opposite. There is a "Start Speed" setting which gives a minimum speed that you need to attain before there is any output power to the motor.
Start Speed.jpg

This is there mostly for sensorless RC type setups that have issues with starting from a dead stop. There's no reason not to have a "PAS Threshold Speed" that requires pedalling above a certain speed but allows throttle only power below that. I'll probably fit this setting in with the PAS setup menu, but haven't implemented it yet.

Is it only germany that has this legislation passed or is it europe wide?

-Justin
 
justin_le said:
A handy feature for the Analogger might also be to dump a short ascii file on startup named CAsetup_XXXX where XXXX is the same as the CAlog_XXXX file. The file would just contain a dump of the setup and advanced setup for the CA - one parm per line in 'name = value' format. Tweaking settings and recording data for test runs would then leave each data log with a corresponding file of the exact setup in use at the time. Although not always useful, the files would be of inconsequential size and easily deleted en mass if unwanted.

That's a great idea for sure. It wouldn't be the Analogger doing this but I could have a small header that the CA itself outputs during the bootup sequence. At the moment it just sends a line that says "V, A, Ah, Sp.. "etc, but it could instead be a header block with a more detailed breakdown of the parameter settings.

-Justin

I implemented something very similar. With the header containing software version, filename, settings, log rate and finally the header row for the data to follow. It was really useful for testing, and meant I didn't have to separately record what I was tuning as it was all in the log file.

The other file I created was a trip summary file. Basically whenever the bike came to rest it wrote or overwrote out to a different file that contained the same "trip number" as the datalog file. It included basically all the summary stats you would see on the display. Trip times, dist, wh, wh/km, average power, max amps, min volts, etc. It was great to automatically record the summary stats for each ride. The downside was that they were each in a separate file, making it a pain to review all the trips. A better method would be to have one file that has a line per trip for all the stats. But this requires different logic on how the file is written, or how you access the file to update the trip stats. Anyway, that would be another killer feature for the CA if you can be bothered doing it.

- Adrian
 
Is it possible to have two temperature inputs and the ability to display BOTH of them on the main display window? maybe one of the other pins could have multiple functions as setup in the settings...for those that intend on monitoring multiple temperature points
 
justin_le said:
At present, in addition to streaming the Volts, Amps, Speed, Distance, and Ah, the V3 also adds to the mix: ...[list of cool things]
:D
justin_le said:
... I could have a small header that the CA itself outputs during the bootup sequence. At the moment it just sends a line that says "V, A, Ah, Sp.. "etc, but it could instead be a header block with a more detailed breakdown of the parameter settings.
8) -- I *like* it! -- Thanks!
 
el_walto said:
I'm interested in the Torque Sensors. Would be nice if i could build pedal and go ebikes for my parents. Not sure if there is going to be anything decent available from ebikes.ca torque sensor wise to go with the CA.

For sure, we have a small number THUN torque sensors on hand (like maybe 6 or 7 left for beta testers) and will be ordering them in some quantity very soon so that we can offer a CA V3+THUN bundle, with pre-made wiring harnesses to simplify the assembly. The input settings for the torque and PAS sensor in the CA itself are pretty flexible, so it's not tied to any specific device and should accomodate anything on the market that has a linear voltage/torque relationship. You indicate the scaling factor in Nm/V (the thun is 100, but we set this to 200 so that it doubles the torque to account for the single sided torque sensing nature of the device):

View attachment 2

Plus you can zero the torque offset, much like the zero amps routing for the current offset:
Trq Offset.jpg

For the pedal cadence sensing, you set the number of pulses per pedal rotation:
PAS Poles.jpg

And if the cadence sensing has a quadrature encoder, then there is a polarity selection to indicate which is direction is forwards and which is reverse pedalling:
Dir Polarity.jpg

All of my testing so far has been done with the THUN X-Cell sensor, for the most part it is pretty good but there are a few slight shortcomings that came up:

1) Magnetic Field Sensitivity: My demo bench was welded up from steel frame bike parts and a lot of the tools in my garage are slightly magnetized, and as a result the test jig has some residual magnetism too. It turns out that the sensing technology is extremely sensitive to external fields, so on my demo setup even with no torque on the bottom bracket, I would see a variation in about +- 10Nm in the signal output just by changing the spindle angle. When I touched my slightly magnetized wrench to the THUN spindle to remove the crank say, then the signal would jump off the scale. On an alloy frame bike this is all of minimal consequence, but I can envision situations with steel frames that have had magnets stuck on them in the past where a degaussing of the bottom bracket area might be necessary.

2) Offset hysterisis, The specified accuracy error of the THUN sensor is 2%, which looks really good at first. However, that is not the linearity error but 2% of full scale. Since it reads up to +- 200Nm, then the output can be off by +- 4Nm, which is a lot if you are only doing light pedalling. If you are averaging like 15-20 Nm which is pretty typical for casual effort, then the accuracy error can reach 20-30%. You can see this first hand by measuring the voltage from the THUN sensor with no torque, then standing and hoping on the pedals, and then looking at the zero torque reading again. If it was 2.49V the first time, it might read 2.52V or so afterwords. Spin the pedals 180 and hop on them again, and the zero torque reading might be 2.47V. That means that for very accurate reading of the human power, it will be important to periodically check and re-zero the thun's torque offset. For just PAS mode it's no issue, but for someone using it as a training aid it's not quite as suited as I had hoped.

3) Spindle length options Thun offers 120, 127, and 136mm spindles which is fine for the large majority of bikes. We thought it would be fun to install one on the Dogati bike after the Taipei show and have maybe the worlds first multi kW pedalec! But the Dogati needs a >150mm spindle for the cranks to clear the motor drive assembly, and lots of other mid-drive ebikes (like the Cycleone-USA stuff) require speciality long spindles too. I'll ask Thun what the minimum numbers would be to have a longer spindle option tooled up, because if we can have it work with the majority of mid-drives as well then that would be sweet.

Here is what the sensor looks like, btw:
THUn BB.jpg

The ST-01 torque sensor being shown by GreenTrans looks like it has a few benefits, namely that it senses both left and right crank torques and also has a wire exit on the side of the bottom bracket rather than through the center, so you don't need to drill a hole through the frame to feed the wire out:
http://www.greentrans.com.tw/eng/download/ebkit_catalogue.pdf
However, the dual sided sensing means that a special adapter needs to be fit to link the chainring to a splined sleeve on the spindle. You can't just use an off-the-shelf crank and chainring on the right side if you want to "see" the right side pedal torque. And when I talked to them, they were really only interested in providing a whole package solution and not so much in supplying just the torque sensor. I'll try to follow-up but don't hold too much promise.

The other supplier is Schaeffler FAG, who do the torque sensing BB's for the Bosch mid drive module. In the press release they also list it as dual left/right pedal torque sensing:
http://www.schaeffler-group.com/content.schaefflergroup.de/en/press/press-releases/press-details.jsp?id=3447045
But I heard indirectly that this is only available to Bosch, and the one that they showed me at the show was single side sensing like the Thun, but instead of with a -200 to +200 NM range, it was a 0-100 Nm range. So it would probably be more accurate at measuring human watts at lower power levels, but would hit saturation when someone is really pushing on the cranks.

Definitely Thun as a company has been most responsive and the easiest to work with so far, so we'll carry their sensor to start, but it's good to see that there could be a few other options for people in this space. The last torque sensor we looked at was YST:
http://www.yst-corp.com.tw/products_view.asp?FkindNo=F000009&SkindNo=&ItemNo=&PidNo=201104150001
Theirs has a non-linear varying resistance to torque relationship, which isn't very practical for device interfacing.

-Justin
 
adrian_sm said:
The other file I created was a trip summary file. Basically whenever the bike came to rest it wrote or overwrote out to a different file that contained the same "trip number" as the datalog file. It included basically all the summary stats you would see on the display. Trip times, dist, wh, wh/km, average power, max amps, min volts, etc. It was great to automatically record the summary stats for each ride. The downside was that they were each in a separate file, making it a pain to review all the trips. A better method would be to have one file that has a line per trip for all the stats. But this requires different logic on how the file is written, or how you access the file to update the trip stats. Anyway, that would be another killer feature for the CA if you can be bothered doing it.

Another really great idea. Best would be if it was right at the top of the header file, so the first thing you see on opening a log file is the trip distance, trip time, wh/km, avg speed, etc. then the list of settings, and then finally the table of raw data. As you say somewhat tricky logic to pull off given that the CA/Logger can get powered down at any random point, especially in our case since the CA and the card writer are two separate devices with only one way communication between them, but I'll see what we can do. There's enough processing power in the analogger that it could scan the entire log file and generate the summary stats and put them on the header quite independent of the CA.

-Justin
 
justin_le said:
dodjob said:
Really nice improvements there! :)
In Europe we have the legal possibility to have a "push/start-help" 'til 6Km/h (without the PAS signal) after this speed a PAS signal is needed to reach "full" speed. Any infos If this could be inplemented or if it eventually already the case? ^^

Yes, at present I have almost the opposite. There is a "Start Speed" setting which gives a minimum speed that you need to attain before there is any output power to the motor.


This is there mostly for sensorless RC type setups that have issues with starting from a dead stop. There's no reason not to have a "PAS Threshold Speed" that requires pedalling above a certain speed but allows throttle only power below that. I'll probably fit this setting in with the PAS setup menu, but haven't implemented it yet.

Is it only germany that has this legislation passed or is it europe wide?

-Justin
GREAT :D I deal currently with cargo bikes (actually Beer-cruiser ^^) and they are really heavy to start specially when "loaded" :D
This should be an European rule. I know 100% that it's the case for Germany but I will check if it's the case in the whole EU.
Again, keep the good work, you rock ;)
Gruß,
H.
*EDIT* Semms to be only the case in Germany. If someone can confirm for other lands in EU that could be great :)
 
This new CA looks BOSS! 8) :lol: :D how can you put enough smileys to express that?!
Haha one question that comes to mind is does this new CA lag when it senses that one of the inputs has exceeded its max value? Or does it just not allow any of the values to be over shot? When I set the CA to not exceed a certain limit it will go over that limit for a brief second or two and then it will adjust the throttle correctly. Would the case be different with this new one?
 
Trackman417 said:
This new CA looks BOSS! 8) :lol: :D how can you put enough smileys to express that?!
Haha one question that comes to mind is does this new CA lag when it senses that one of the inputs has exceeded its max value? Or does it just not allow any of the values to be over shot? When I set the CA to not exceed a certain limit it will go over that limit for a brief second or two and then it will adjust the throttle correctly. Would the case be different with this new one?
It is the gain values set in your CA that govern how fast the unit responds to a limit being exceeded, you can change these yourself in the one you have, well i can in the 2 i have, v2.2 and v2.25.

Simon.
 
nice..... I dont know how I missed this thread.

We are in the middle of implementing a wireless IR temperature sensor that can be mounted to the rear drop aiming at the motor. We have a tiny black box with an arduino nano shield that translates the I2C coming out of the IR sensor... which we initially intended to use to directly retard the throttle.... Now it looks like we can just scale this signal and PWM it out to your RTD input as a direct control voltage. The CA will read it just like an RTD input - but now folks wont have to open their motors up to have temperature protection.

This will be good :)

We have been working on some code that monitors the rate of change of temperature on the cover of the motor to predict the winding temperature internally. Smart, wireless, temperature sensor....

Parts have already arrived, prototypes are in the works.

The CA just keeps looking better and better to me. It was the first piece of ebike equipment I ever owned and I still think of it as a critical part of every ebike - as critical as the battery, motor, and controller.

Keep up the good work

-methods
 
I'm loving this thread. I couldn't wait for the new one allready and now talk about wireless temp sensors!!!
 
johnrobholmes said:
The throttle mapping is just icing on the cake! I can use them for any controllers now, what a great piece of kit.

Ever get any farther on integrating a watt controlled throttle or integrating amp limiting with speed limiting throttle types?

It would be epic if we cold program the CA To change the watts limit on the fly based on speed. That would solve a lot of the instant wheelie problems at low speed with a high power setup. I suppose it would have to be implemented in a safe way so that to arent suddenly launched when you are on a borderline limit. Maybe a buffer if some sort would be appropriate... Or maybe like this:

Say you have 2 speed ranges for 2 corresponding watts limits + 1 additional overdrive limit that can be called at any speed. Whenever you are 0-10 unitspod speed your limit is 1000W. When you hit 11 in speed it retains the set 1000W limit until to let go of the throttle completely.. Then when you resume throttle and you are above 10 you will see the second limit you set of say 2000W. Then whenever you want to map the full current range to the throttle you double tap the the bottojm of the throttle and you are in unlimited mode!
 
Awesome product mate..

Sorry if this has been asked before, but is the output voltage of the cable for powering lights on the handlebars configurable via the CA? As in the cable for powering my front lights on my bike. I am about to wire up the front lights on my first e-bike, and when i noticed that cable coming out of the CA, i was jumping in joy. Now i just need to know if i have to wire a dc-dc step down in between or if the CA can do it for me..

Thanks heaps..

and keep up the great work mate..

cheers,

Ed.
 
stripedtuna said:
Awesome product mate..
Sorry if this has been asked before, but is the output voltage of the cable for powering lights on the handlebars configurable via the CA?

Ah good questions. It's a direct tap to your battery voltage, so if you want to run a 6V or 12V device you'd hook up a DC-DC to the power plug on the CA. If you're light has a wide ranging input range that includes the pack voltage then it can plug in directly.

I'm a pretty big fan in the idea distributing the pack Vcc directly for powering peripherals like lights, rather than having separate 12V converters and low voltage busses scattered about. Problem with having a converter on board is that you are then constrained in wattage. If you decide a 20W DC-DC, then people with a 25W lighting system won't be able to use it, while people with a 1W light or no lights at all are paying for a much larger DC-DC than they need. If you distribute power at pack voltage and have each device with it's own appropriately sized internal DC-DC, then there is no need/expense of a converter, and no limit (other than the wire gauge) on how many devices you can hook up.

-Justin
 
I love the new updates cant wait until I can buy one.

Here's to hoping you put up some more videos of your travels to China and to see cell_man.. I very much enjoyed
all the other videos I have seen.

Great job doing things right.
 
Trackman417 said:
Haha one question that comes to mind is does this new CA lag when it senses that one of the inputs has exceeded its max value? Or does it just not allow any of the values to be over shot? When I set the CA to not exceed a certain limit it will go over that limit for a brief second or two and then it will adjust the throttle correctly. Would the case be different with this new one?

This requires a long answer to go in detail, but the short answer is that if the CA's output is directly controlling the throttle input of the controller, then there is almost no overshoot. An output change on the CA is almost instantly translated by the controller (unless your controller has a response lag). The CA V3 really lends itself to this type of wiring, with a separate and dedicated throttle input line.

In the CA V2, most of the time it is hooked up as a "throttle over-ride" device, where the user's throttle goes directly to the controller instead of to the CA. In that arrangement, the CA has no idea what voltage the users throttle position is set at when it senses a limit being exceeded. So all it can do is start off at the full output voltage (ITermMax), and ramp its way downwards until it sees that it is having an effect at reducing power. So if your throttle is at 2V and you suddenly exceed a limit, the CA has to ramp down from ITermMax (say ~4V) down to 2V before anything can happen, and in that time period there is usually an overshoot. There is simply no way for the CA to know that it could have immediately jumped to 2V before it can start doing a more gradual regulation.

When the CA itself IS the throttle, not just a throttle over-ride, then in the above scenario the CA's output is already at 2V when it sees the limit exceeded. And so there is no latency for a change in the CA's output to change the current draw in the controller. Hopefully that makes sense.

So if you hooked up a V3 CA in throttle over-ride mode, it would be the same behaviour with overshoot, but as a direct throttle control it would be instant.

-Justin
 
methods said:
We are in the middle of implementing a wireless IR temperature sensor that can be mounted to the rear drop aiming at the motor. We have a tiny black box with an arduino nano shield that translates the I2C coming out of the IR sensor... which we initially intended to use to directly retard the throttle.... Now it looks like we can just scale this signal and PWM it out to your RTD input as a direct control voltage. The CA will read it just like an RTD input - but now folks wont have to open their motors up to have temperature protection.
This will be good :)

That's an awesome idea Methods! Indeed knowing both the motor surface temperature and the rate of change of surface temp, you should be able to do a decent prediction on the core temperature inside the hub. The results would be very different for when the hub is moving vs. still since convective cooling goes up like an order of magnitude with air flow, but if there's an IR temp sensor pointing at the motor there can just as well be an optical tachometer to let you know if it's spinning. Hey and if you have amassed some amount of data on the internal hub temperatures under moving conditions, this would be really useful to me for making a more realistic "over-temp" predictor on the simulator too.

Yes just filter the PWM and send a voltage signal to the V3 CA, it will both display the temperature to the user and also look after the throttle rollback. It's like the two projects were made for each other :)

Keep up the good work -methods

You too, -Justin
 
gensem said:
Can you give us an aproximated ETA Justin?
Great Job!

Yes indeed. So the availability situation is this: We have about 30 additional V3 CA boards already soldered up in Vancouver, but they all still require some rework as we've realized the need to change a few component values around. Sometime in the next 7-10 days we'll be able complete the assembly and make the 30 pcs available for beta testers. A that point I'll post the details here on how interested people can sign up! If the 30 pieces fly out the door and some people are left disappointed, then we could do a few more mini batches like that every couple weeks.

For us the main time consuming issue is preparing the cable wiring harnesses, so the more beta testers can look after soldering up accessory wires to the PCB themselves then the easier it will be to get small runs done.

The first full scale production batch and general availability is about 8-10 weeks from now, barring no unforeseen parts supply issues. Really hoping that everything on that front goes smoothly since I'm as excited to see this move forwards as you are.

-Justin
 
Back
Top