Cycle Analyst V3 preview and first beta release

[teklektik]

Excellent news! This was a good line of questions that cleared up the legacy mode configuration.

[Joe Perez]

(The default Ti of 0.37v when disconnected seems odd - I would have expected it to be pulled down to 0v, but that's another question not directly related to this situation....)

I'm going to take a wild guess and say that this may be related to hardware rather than software.

When I was tinkering with my CA3 to accomodate an LM35 temperature sensor (as opposed to the officially-sanctioned LM335 or NTC sensors) I found that even after removing the "NTC" pullup resistor, my Temp input tended to float high and was influenced by the throttle. (Higher throttle input = higher Temp indication.)

Apparently there is some crosstalk between the various analog inputs (or at least between the throttle in and the Temp in) owing the multiplexed nature of the A-D converter. Since the LM35 I was using is a current source but cannot sink current, this crosstalk was not masked as it would have been otherwise. In my case, this was solved by placing a ~390 ohm pulldown resistor between the "NTC" pad and ground.

Could it be that in the absence of an actual throttle sensor that the same phenomenon is taking place on the throttle input line? I'll bet you €1 that putting a resistor between the throttle input and ground will make this go away. As a test, it can be done externally at the throttle input connector.

[teklektik]

I'm going to take a wild guess and say that this may be related to hardware rather than software.

When I was tinkering with my CA3 to accommodate an LM35 temperature sensor (as opposed to the officially-sanctioned LM335 or NTC sensors) I found that even after removing the "NTC" pullup resistor, my Temp input tended to float high and was influenced by the throttle.

Apparently there is some crosstalk between the various analog inputs (or at least between the throttle in and the Temp in) owing the multiplexed nature of the A-D converter. ... In my case, this was solved by placing a ~390 ohm pulldown resistor between the "NTC" pad and ground.

Could it be that in the absence of an actual throttle sensor that the same phenomenon is taking place on the throttle input line? I'll bet you €1 that putting a resistor between the throttle input and ground will make this go away.

I remembered your experience and believe this to be hardware-related. I recently had a similar experience while hooking up the Analogger to record my external Vaux limit switches - even the same open-circuit voltage. A pulldown was one effective solution with that issue as well, although I went a different way in the end.

On the other hand, this voltage is only manifest when Thi is disconnected. Although the non-0 value at first just appeared harmless and curious, it actually turns out to play a key role in the settings required for legacy Throttle Override operation. Forcing Thi to zero will break the current configuration solution, requiring implementation of a software alternative. So - assuming there is a good electrical reason for this phenomenon (i.e. it's not just an accidental component side-effect), it seems best to leave things as they are and continue to exploit the default open-circuit voltage as part of the legacy software config.

[Joe Perez]

Well, yeah. The best thing, obviously, would be to have the throttle actually connected to the CA3 as it's intended to be. Most (all?) throttles I've seen, be they hall or resistive, seem to be perfectly capable of sinking tiny amount of current on their input, which would make this leakage a non-issue when "used as intended."

Maintaining legacy compatibility like this is always a constraint in any integrated system design.

[courcheval]

Justin, I have a bit more data on the speedometer issue, but I'll address your question first:


1: If I am already moving forward at a decent rate of speed (pedaling) when I switch the unit on, I don't see the phenomenon as dramatically on the realtime speedo display (it might only get up to 50-100 MPH) however MaxS still records a peak in excess of 400 MPH.

2: If I switch speedo units to Km instead of Mi, the glitch goes away completely. When I switch back to Mi, it comes right back.

On my first trial of Tench s prototype, the Max Speed indicated was 601 Km/h. I have a serious problem since the max speed on highways is 130 km/h!

[lizardboy]

Hi Justin;

I'm setup in miles not Kms sorry. Although I have switched back and forth before

I had a unrelated problem recently where the bike cut out and would only run the motor for a quick jolt. I checked the output signal in the real time menu and it was working perfectly. It seemed exactly like there was a problem with the hall sensor wiring so I checked everything and found nothing wrong. I'd been wanting to shorten the motor wiring for a while so I did. I also changed the setting for the voltage that the CA shuts down. It had been 10 volts and I set it to 26 volts. I don't seem to have the problem now as bad. if I stick to only using the keyswitch to turn all the power off I'd say it working 100%
the odd time that I've tried the throttle button, the system it seems to work after but is a bit jerky in current throttle and will cut out once in a while but can be reactivated by twisting the throttle. Cycling the main power seems to eliminate it. I've still got all the limiting turned off.

Perhaps because my throttle is powered by the controller and not by the CA there is a power sequencing issue introduced. Not sure but currently it works pretty well.

[justin_le]

Hey guys, sorry for the long lapse since last update, had a lot of other engineering projects on the burner needing attention.

Attached is a Beta16 version of the code. EDIT, Firmware had corrupted Zero Amps routine, please download more recent file
Some of the minor things changed since Beta15:

* Erroneously high max speed glitches fixed. Both the problem with with it booting up in ~400mph when in the miles, and an issue that could cause high MaxS if wheel was spinning while the CA was being powered on.
* Increased the window for showing low speeds, so for a standard 26" wheel it can now work down to ~3mph OK
* Modified the display for the "Set Temperature" window so it shows in realtime not just the voltage but also the calculated temperature
* Leading zeros are eliminated for items in the setup menu. I'm not 100% sure about this, the leading zeros always bugged me a bit, but then toggling digits into a 'blank' space has some oddness too.
* Made the state of charge algorithm better detect when it thinks that system power is being shut off so it doesn't go towards 0% SOC as power unplugged.

Plus two more significant updates:

#1) New Display for showing the diagnostics which should help with some system debugging. The top line shows the reatime input and output throttle voltages. The bottom left has a set of characters showing which if any limits are currently active. Each of the overcurrent current, power limit, max speed, low voltage, and threshold temperature, are represent by their respective letters, and go from lower to upper case when limits are reached.

CA Limit Flags.jpg (62.26 KiB) Viewed 757 times

#2) Addition of two battery presets. At the start of the battery setup menu, you can choose if you are currently dealing with battery A or battery B. The CA then keeps a separate set of settings for each battery, so the chemistry, cell count, nominal amp-hours, total cycles, low voltage cutoff, and total amp-hours are all specific to pack A or pack B. This will naturally be appreciated by people who run a couple different batteries with their ebike, and is also something of a precursor to having a similar set of "mode presets". At the moment you can only change between batteries in the setup menu, but it's in the works to do it via a 2-button sequence as a shortcut.

Battery A or B.jpg (18.56 KiB) Viewed 757 times

-Justin

[justin_le]

Is the v3 coming onto the market any time soon? Thx.

I've been holding off saying anything to this because it's always a jinx to publicly or even privately post a timeline. But, it is looking like everything is properly in place for the first production units to be finished and available by the end of this month. In the meantime, we still have a couple dozen from the Pilot batch which will now be programmed with the Beta16 code and made available again for beta testers. More details on that tomorrow.

-Justin

[justin_le]

Hi Justin;

I'm setup in miles not Kms sorry. Although I have switched back and forth before

I had a unrelated problem recently where the bike cut out and would only run the motor for a quick jolt. I checked the output signal in the real time menu and it was working perfectly. It seemed exactly like there was a problem with the hall sensor wiring so I checked everything and found nothing wrong.

I would check that the output of the CA isn't hitting the throttle input fault voltage of your controller. Set the CA's throttle output to go all the way to 5V. Then slowly ramp the throttle up until the controller shuts down from throttle overvoltage fault, note where it happens and set the max throttle output of the CA at least 0.25V less than this. Most of the infineon style controllers have their throttle powered from about 4.3V instead of 5V, so the throttle input range is 0.8-3.6V instead of the more common 0.9-4.1V, and we've seem some go into a fault mode at 3.7V.

the odd time that I've tried the throttle button, the system it seems to work after but is a bit jerky in current throttle and will cut out once in a while but can be reactivated by twisting the throttle. Cycling the main power seems to eliminate it. I've still got all the limiting turned off.

Let me know if you still have this occurrance with the B16 firmware. And if so, hopefully the diagnostic screen that shows which limits are kicking in will be able to shed some light!


-Justin

[teklektik]

#1) New Display for showing the diagnostics which should help with some system debugging. The top line shows the reatime input and output throttle voltages. The bottom left has a set of characters showing which if any limits are currently active. Each of the overcurrent current, power limit, max speed, low voltage, and threshold temperature, are represent by their respective letters, and go from lower to upper case when limits are reached.

This is huge! Very slick and compact view into the inner workings...

[hjns]

I love it. Ordered another V3 beta and Thun torque sensor for my 2WD setup.
Anxious to see those details...

In the meantime, we still have a couple dozen from the Pilot batch which will now be programmed with the Beta16 code and made available again for beta testers. More details on that tomorrow.

-Justin

[teklektik]

Setup Summary for CA v3B16/v3B17

The setting summary for the newer v3B19 release is available here.
The setting summary for the previous v3B15 release is available here.
Unofficial basic setup notes are available here.
Values shown are defaults after loading firmware.

[...] = numeric entry field
{ ... | [...] } = menu chooser where [...] = default selection

1. Setup Calibrtion
   
   1. Cal -> Range
      { [Lo (W)] | Hi (kW) }
   2. Cal -> RShunt
      [1.000] mOhm
   3. Cal -> V Scale
      [31.05] V/V
   4. Cal -> Zero Amps
      (Press/Hold to normalize the currently detected Amp reading to 0.0)
2. Setup Spdometer
   
   1. Spd -> Units
      { mi | [km] }
   2. Spd -> Wheel
      [2075] mm
   3. Spd -> #Poles
      [1]
   4. Spd ->TotDist
      [0] km
3. Setup Speed Lims
   
   1. SLim -> Max Speed
      [99.0] kph
   2. SLim -> Start Speed
      [0.0] kph
   3. SLim -> IntSGain
      [200] Gain
   4. SLim -> PSGain
      [.59] V/kph
   5. SLim -> DSGain
      [2] Gain
4. Setup Power Lims
   
   1. Plim -> Max Current
      [99.0] Amps
   2. Plim -> AGain
      [150] Gain
   3. Plim -> Max Power
      [9900] Watts
   4. Plim -> W Gain
      [50] Gain
5. Setup Throt In ........ Live Data = < 0.00V >
   
   1. ThrI -> Cntrl Mode
      { [Pass-thru] | Current | Speed | Disabled }
   2. ThrI -> Min Input
      [.99] Volts
   3. ThrI -> Max Input
      [3.99] Volts
   4. ThrI -> Fault Volt
      [4.49] Volts
6. Setup Throt Out
   
   1. ThrO -> Output Mode
      { [Voltage] | R/C Pulse }
      (if ThrO->OutputMode = { Voltage }
      
      1. ThrO -> Min Output
         [.90] Volts
      2. ThrO -> Max Output
         [3.74] Volts
         )
      (if ThrO->OutputMode = { R/C Pulse }
      
      1. ThrO -> Min Output
         [.90] mSec
      2. ThrO -> Max Output
         [3.74] mSec
         )
   2. ThrO -> Up Ramp
      [500]
   3. ThrO -> Down Ramp
      [500]
   4. ThrO -> KV Comp.
      [.95] V/kph
7. Setup RPM Sensor ........ Live Data = < Rev Hi >
   
   1. RPM -> PAS Poles
      [08]
   2. RPM -> Dir Plrty
      5v={ [Fwd] | Rev }
   3. RPM -> Quadrtr
      { Disabled | Enabled }
   4. RPM -> Strt Delay
      [40] x 18ms
   5. RPM -> Stop Delay
      [25] x 18ms
8. Setup Trq Sensor ........ Live Data = < 4.46V >
   
   1. Trq -> Trq Scale
      [-200.0] Nm/V
   2. Trq -> Trq Offset
      {2.49V 4.46}
      (Press/Hold to update eeprom offset voltage on left with current voltage on right - similar to Zero Amps)
9. Setup Cntrl Mode
   
   1. Ctrl -> PAS Mode
      { [PAS Off] | RPM Cntrl | Trq Cntrl }
   2. Ctrl -> Assist Level
      [500] mA/Nm
   3. Ctrl -> Aux Funct
      { [Off] | Amps Lim | Speed Lim | Power Lim | Pas Level }
   4. Ctrl -> Min Aux In
      [.99] Volts
   5. Ctrl -> Max Aux In
      [3.99] Volts
10. Setup Temp Sensr
    
    1. Temp -> Sensor ........ Live Data = < 4.91V 0.0o >
       { [Disabled] | 10K Thrmstr | Linear Type }
       (If Temp->Sensor = { Linear Type }
       
       1. Temp -> 0 Deg
          [.99] Volts
       2. Temp -> TScale
          100.0 Deg/V
          )
    2. Temp -> Thrsh Temp
       [90] oC
    3. Temp -> Max Temp
       [130] oC
11. Setup Battery
    
    1. Batt -> A or B
       { [A] | B }
       (if Batt->AorB = { A }
       
       1. Batt -> Chemistry
          { [LiMn] | LiPo | LiFe | SLA | NiMH }
       2. Batt -> String#
          [10] Cells
       3. Batt -> Capacity
          [10] Ah
       4. Batt -> Vlt Cutoff
          [19.0] Volts
       5. Batt -> V Gain
          [800] Gain
       6. Batt -> TotCyc
          [0] Cyc
       7. Batt -> TotAhrs
          [0] Ah
          )
       (if Batt->AorB = { B }
       
       1. Batt -> Chemistry
          { LiMn | LiPo | [LiFe] | SLA | NiMH }
       2. Batt -> String#
          [16] Cells
       3. Batt -> Capacity
          [15] Ah
       4. Batt -> Vlt Cutoff
          [39.0] Volts
       5. Batt -> V Gain
          [800] Gain
       6. Batt -> TotCyc
          [0] Cyc
       7. Batt -> TotAhrs
          [0] Ah
          )
12. Setup Display
    
    1. Disp -> Main Disp
       { [Watts] | Amps }
    2. Disp -> Averaging
       [5] Duration
    3. Disp -> RS232
       { [1] | 5 } Hz
    4. Disp -> Vshutdown
       [10.0] Volts
    5. Disp -> Stop Scrns
       [11111111111]
       (Binary digits select display of 11 screens starting with Main)
    6. Disp -> Movn Scrns
       [11111111011]
       (Binary digits select display of 11 screens starting with Main)

Printable version:

CA_v3B16_ConfigSettings.zip

(1.56 KiB) Downloaded 32 times

[teklektik]

Some of the minor things changed since Beta15:

* Leading zeros are eliminated for items in the setup menu. I'm not 100% sure about this, the leading zeros always bugged me a bit, but then toggling digits into a 'blank' space has some oddness too.

FWIW I vote for leading zeros. Since there is no shorthand available to skip entering them (e.g. enter '10' instead of '0010'), I find the blank space unhelpful for data entry. Mentally measuring the space to get the needed alignment seems less intuitive than simply using the leading zeros as visible place holders.

Plus two more significant updates:

#1) New Display for showing the diagnostics which should help with some system debugging...

Although space had to be released to implement this cool screen, I do miss the displaced Vaux display (which admittedly does not have a huge audience). I much prefer the new version with limit flags but if you can find a way to squeeze in Vaux somewhere in the future, it would be good

[Joe Perez]

Very cool, Justin. I'll flash this in tonight. Thanks for all the continued work here- you've got a heck of a great product on your hands.

[teklektik]

#1) New Display for showing the diagnostics which should help with some system debugging. ... The bottom left has a set of characters showing which if any limits are currently active. Each of the overcurrent current, power limit, max speed, low voltage, and threshold temperature, are represent by their respective letters, and go from lower to upper case when limits are reached.

Now that we have these handy limit flags to call attention to internal state, I notice that even with the temp feature disabled, temp limiting is active if Temp->MaxTemp is incorrectly configured less than Temp->ThrshTemp (e.g. limiting is in effect with: 'disabled', apparent temp = 0.0 degrees with no attached sensor, MaxTemp=899 , and ThrshTemp=999 ).

Detection of improper configuration is good, but it seems this verification should be inoperative if temperature monitoring is disabled. This is a very small thing, but the behavior seems needlessly fussy rather than intuitive....

[justin_le]

Now that we have these handy limit flags to call attention to internal state, I notice that even with the temp feature disabled, temp limiting is active if Temp->MaxTemp is incorrectly configured less than Temp->ThrshTemp (e.g. limiting is in effect with: 'disabled', apparent temp = 0.0 degrees with no attached sensor, MaxTemp=899 , and ThrshTemp=999 ).

Ha, indeed I haven't gone through and done proper boundary case checking, so if you set the threshold temperature higher than the max temp, or if you set the min throttle higher than the max throttle, or anything like that, the behavior at the moment will be pretty ill-defined. I'll make a note to address this in next firmware so that it will constrain input values that are outside of sensible range. So MaxTemp will always be forced higher than ThrshTemp when you try to change it, and then the above scenario could never manifest.

FWIW I vote for leading zeros. Since there is no shorthand available to skip entering them (e.g. enter '10' instead of '0010'), I find the blank space unhelpful for data entry. Mentally measuring the space to get the needed alignment seems less intuitive than simply using the leading zeros as visible place holders.

Thanks. I think if the leading zeros didn't have the diagonal cross through them they would be more palatable. Perhaps the best option might be to hide leading zeros when you are scrolling through the display to look at the values, but then have them appear the moment you hold the button to edit any of them?

-Justin

[teklektik]

I'll make a note to address this in next firmware so that it will constrain input values that are outside of sensible range. So MaxTemp will always be forced higher than ThrshTemp when you try to change it, and then the above scenario could never manifest.

excellent!

Perhaps the best option might be to hide leading zeros when you are scrolling through the display to look at the values, but then have them appear the moment you hold the button to edit any of them?

That would give the best aspects of both approaches...
+1!

[hillzofvalp]

I'm noticing more nd more relevance in having the aux input voltage constrained and/or modified to prevent bike from launching when throttle wire breaks. If you have implemented this Already, I'm that much more motivated to buy another CA, especially as I take the power up to 8kW.

Please revert any vAlue other than the range from minimum throttle input to max to the aux threshold value known to the controller as 0 throttle (ca corrected throttle output). I may have missed if you recognized he issue. All it takes is a flying tree branch or uninformed user doing sketchy soldering to send him flying into someone's bumper

[justin_le]

This will be a long post with some background to clarify how to connect the V3 CA devices to a controller via 6-pin direct plug. When the idea of using the original DrainBrain was being upgraded to not just monitor but also regulate a motor controller, we were using the analog Crystalyte controllers and those had an 'ebrake' input that was literally just a diode link to the throttle signal, so that when the brake levers were squeezed then the throttle signal got pulled to ground via D3, while the 5K resistor R29 limited the current pulled from the throttle in this scenario:

Clyte Throttle Schematic.jpg (33.27 KiB) Viewed 919 times

That made it very convenient to simply tell Crystalyte to connect the CA's throttle over-ride pin to the existing ebrake pad, and then the CA would have not just on/off but even linear regulating capabilities to the controller. And since the diode was already internal to the circuitboard, we could rely on that to prevent the CA from driving the controller directly, only allowing it to pull down or limit the existing throttle.

Clyte controller with 6-pin connector.jpg (45.17 KiB) Viewed 919 times

However, as the controllers evolved to digital designs, the ebrake input became a separate digital port to the onboard micro, and naively connecting the CA-DP plug to this would reduce the CA's limiting ability to jerky on/off control. So then we had to clarify with Crystalyte that the Throttle over-ride pin still needed to be attached via a diode to the throttle line, and since that diode wasn't already on board, a bit more 'hacking' was required. In most cases, the controllers had various other circuitry and pads wired to the throttle line, and replacing a resistor here with a diode allowed for the same functionality:

Ebrake Connector Details.jpg (37.17 KiB) Viewed 919 times

Ebrake Connector Modification for Crystalye Controller.jpg (59.89 KiB) Viewed 919 times

Thus, the "Direct Plug-in" controller standard always had this diode requirement, which in some cases was a bit complicated. With controllers that didn't have a convenient schematic hack, the diode was often wired inline with the wires and this was a source of some failure when the solder joint was weak

Green Wire through Diode.jpg (25.82 KiB) Viewed 919 times

Since 2011 we decided to make the situation a bit easier by including the diode onboard the Cycle Analyst itself. So on any CA PCB Rev11 or later, you will notice that the green wire of the CA-DP is soldered to a pad labelled ThO, while the original Th pad (pre-diode) has moved up to the top. This way there is no longer a need for a diode inside the motor controller, though if there is a 2nd diode that's no problem either. However, if someone wants to use the CA as say a current throttle and not just as a limiting device, then they would need to ignore the ThO pad and wire their system up to Th.

Throttle Diode Details.jpg (46.56 KiB) Viewed 919 times

[justin_le]

With the V3 CA devices, the functionality of the CA now includes not just throttle limiting, but actually driving the controller's throttle signal directly, and this is NOT possible if there is a diode inline with the throttle signal. So, if you have a CA-DP compatible controller and want to use the CA-V3 device as your new throttle, you will need to do a bit of modification. Here are 3 approaches:

#1) Swap pins around so that the green wire from the CA-DP goes into the controller's regular throttle input. You can either do this at the CA-DP plug end as shown below, or you could do it on the controller end:

Plug Rewiring.jpg (43.37 KiB) Viewed 912 times

#2) Insert a short between 5V and your throttle signal. This way the throttle signal is being pulled high by the short circuit, and so the CA only needs to pull the signal down from there which it can do via the diode. This method is easiest for sure, however, it is crucial that you only do it if your controller has a proper over-throttle voltage fault. Otherwise, if you unplug the CA then the controller will take off full tilt as the throttle input is at 5V. You want to be sure that the controller treats this situation as a fault and shuts down.

Throttle Short.jpg (16.53 KiB) Viewed 912 times

#3) Open up the controller and replace the diode with a ~500-1000 ohm resistor. Depending on where your controller is from, the diode may be a surface mount device on the PCB or a clearly obvious inline diode to the green CA wiring. While you could in principle completely short out or bypass the diode, this isn't recommended as then the CA will usually be directly connected to the microchip which can be an issue if your ground connection fails. A 500 to 1000 ohm resistor will provide some protection.

For all controllers going forward, we are working on a formal spec document for a CA V3 compatible plug standard, which is similar to the #3 modification above. Basically, both the CA plug and the Throttle are connected to the controller's throttle input, but via resistors so that the CA has a closer connection to the signal going to the microcontroller. For instance, with our current 12 mosfet infineon boards the original CA wiring used to be as follows:

Original CA-DP Plug.jpg (31.41 KiB) Viewed 912 times

We have now spec'd it like this, where the regular throttle signal needs to go through a 10K resistor to reach the microchip, while the CA's throttle signal only has 1K in it's path.

New CA-DP Plug.jpg (23.83 KiB) Viewed 912 times

So the resulting pinout is simply

CA V3 Wiring.jpg (34.18 KiB) Viewed 912 times

This scheme has the following benefits:

• Controller still works with no CA attached, just plug a throttle and away you go
• Controller is compatible with a throttle + V2 CA for limiting, provided that it is a CA2 with Rev11 or later PCB.
• Controller is plug-in compatible with a V3 CA device acting as the throttle.

The only drawback is that if someone attaches a pre-2011 Cycle Analyst device that doesn't have the diode built in (Rev10 PCB or earlier), then it could potentially cause the ebike to take off when the CA is plugged in.

-Justin

[hillzofvalp]

Thanks for the timely response and advice. I will look into it further during the next rebuild.

[Bartimaeus]

Will the v3 still have the 5mA limit for powering external circuits via the 5v pin? Trying to run Sparkfun's OpenLog from the CA, and it just barely works at the 1Hz data rate. Every time it goes to write the screen flickers, and since the peak current draw is listed as 6mA for the OpenLog I was going to look into re-programming it so the indicator LEDs wouldn't flash when writing to the microSD or as a last resort breaking/desoldering the LEDs. But if the new one has more leeway it won't be an issue anymore.

[justin_le]

Will the v3 still have the 5mA limit for powering external circuits via the 5v pin?

Yes, the basic regulator topology is the same.

Trying to run Sparkfun's OpenLog from the CA, and it just barely works at the 1Hz data rate. Every time it goes to write the screen flickers, and since the peak current draw is listed as 6mA for the OpenLog I was going to look into re-programming it so the indicator LEDs wouldn't flash when writing to the microSD or as a last resort breaking/desoldering the LEDs. But if the new one has more leeway it won't be an issue anymore.

If it is indeed just 6mA even during the flash writes to the card then you should be fine. The 'flicker' that you see is just the result of changing current through the backlight resistor which happens when the current draw on the 5V line is changing, it's not a sign that the CA is suffering. You can eliminate the changing backlight brightness by tapping off power from the 10V rather than the 5V bus, which you can access from the 2nd pin of the LCD header under the "+" from "-LED+". Only downside is that the CA might not save data completely when you power it down, but if you have the logger attached then that shouldn't be much of an issue.

-Justin

[jonescg]

Hey Justin!

Just double checking, 650 V is the absolute maximum voltage detectable through the CA, even with a voltage divider?

Damn. I'm going to be running 700 V top of charge on the race bike. I guess I could scale it by a factor of 10, but that would also mean the Wh used will be out of whack too... Hmm Any chance of an increase in the range of Vsense?

Cheers,
Chris

[Bartimaeus]

Thanks Justin! That helps a ton!

Farfle just suggested using a capacitor as a buffer to eliminate the flickering, and the OpenLog is small enough that it won't be too difficult to fit it inside the CA case with a small cutout to access the card. Will post pics when it's done