Executive summary

It was found that BalenaFIN boards did not perform well in elevated ambient temperatures.

Balena did an root cause analysis and issued an fix.

We did some tests (described in this post) that verified that fixed boards work ok at least in ~73 C ambient temperature for 8 hours.

Description of project

It was found that our BalenaFIN based products are not working correctly at elevated ambient temperatures. This was also the case in deployed installations at our client sites where elevated temperatures are often found due to hot process environment. During summer 2020 we were forced to add extra cooling to deployed devices at field as quick fix for the problem.

As soon as our clients reported possible temperature problems, we did small change to our deployed software to read internal temperature from BalenaOS  /sys/class/thermal/thermal_zone0/temp and send it to our cloud. So we have temperature data from failed units and can thus compare readings.

These pre-fix boards have failed when this internal temperature was between 60-70 C. Unfortunately we don’t have any ambient measurement data available for those deployed pre-fix boards.

After extended testing Balena found an issue on their board that affected board stability at high temperatures. An resistor value was found to be wrong and thus resulted to wrong voltage levels that resulted in internal components being powered off. Based on testing Balena changed the resitor value to more suitable value. Detailed root-cause analysis can be found from https://www.balena.io/blog/usb-issue-rca/.

We ordered new boards immediately when they were available after Balena released information about this fix.

Test aim

• Phase1
  • We shall test that ambient temperature of ~70C is not an issue for BalenaFIN by heating bare BalenaFIN in heat-chamber to ~70C ambient and log the performance for one full workday (8h).
• Phase 2
  • If phase 1 succeeds, we shall test with ethernet sensor connected
• Phase 3 (optional)
  • When we have new batch of mPCIe modems, we should test with the modem we are using to verify out also mPCIe working

Test setup

• BalenaFIN board (new fixed revision, received from Balena 2020/08)
• Memmert UM200 laboratory heat-chamber
• Fluke T3000FC temperature logger
• IFM AL1350 industry IoT ethernet-board
• IFM TV7105 IO-LINK temperature probe
• AIM TTi laboratory bench power supply with 24V output
• Software to read and log /sys/class/thermal/thermal_zone0/temp temperature reading

Test decription

Phase 1: Bare BalenaFIN – board 8 h

• Laboratory heat-chamber was heated to approximately 73C
• BalenaFIN was put inside chamber to FR4 base
• Fluke-temperature probe was put inside chamber and logging was started
• BalenaFIN started to send temperature values to cloud and these were monitored and logged for 8 hours.
• Graphs were drawn with ambient temperature from Fluke temperature logger and internal temperatures sent by BalenaFIN and checked that Balena did send temperature to cloud whole time.

Fig 1: Test chamber temperature readings of 73 C during 8 hour test period.

Fig 2: Internal temperatures reported by Balena. About 91 C.

It was found that Balena worked correctly during this test so proceeded to phase 2.

Phase 2: With ethernet connected, 3 h

• Same setup and test procedure as in phase 1 but heat chamber temperature was measured also with IFM IO-link industrial sensor connected to ethernet. If USB power is missing, this should show in data as per Balena’s report, ethernet bridge is also USB-based.

Fig 3: 3 hour heat chamber temperature and balena internal temperatures. Heat chamber temperature measured with ethernet sensor to see if ethernet is stable.

 

BalenaFIN was found to be correctly sending both values whole time.

Conclusions

We verified that at least BalenaFIN unit we tested was successfully able to withstand 73 C ambient temperature without failing.

So the fix that Balena did seems to be working.

Possible next steps

To replace every distributed board at customer sites with a fixed board and send broken boards back to Balena for RMA repair.

If needed, heat chamber tests with mPCIe modems used in application could be done also.

 

Test time, location and participants

2.-4. Sep. 2020

PalonenLABS Oy workshop, Tampere, Finland

Henry Palonen / PalonenLABS Oy

I have bought few Fluke Connect modules and they seem to work nicely. They allow me to remotely measure voltage, current and temperature. Handy if I just want quickly to measure and possibly log something in our projects. I have also an FC-module for my logging multimeter (Fluke 289) but it’s currently at our “electrical motor-testing cave” so it did not make it to this group photo 🙂

One feature missing is the ability to integrate measurements to my own .Net C# software. So I searched high and low for protocol documentation or programming API for these devices. I didn’t find anything so today I spent few hours to investigate this issue.

Few hours later I’m able to read Fluke V3001 FC voltage module from my own software so success!

Here is how I did it.

As Fluke PC3000 FC adapter seems to present itself to PC as a serial port, I started an serial port sniffer tool and read the communication between PC and original Fluke Connect software.

Here is one capture of where device is discovered and then live view displays data from one voltage module;

<COM7: 20170920141932.813 TX>
id
<COM7: 20170920141932.831 RX>
CR:Ack=0:ID:FLUKE PC3000FC,V01.02.00,0
<COM7: 20170920141932.833 TX>
rfsm 1
<COM7: 20170920141932.844 RX>
CR:Ack=0:RFSM:Radio On MasterRE:M
<COM7: 20170920141939.470 TX>
rfdis
<COM7: 20170920141939.509 RX>
CR:Ack=0:RFDISME:S
<COM7: 20170920141949.062 RX>
ME:D:010000000000
<COM7: 20170920141949.075 TX>
rfebd 01 0
<COM7: 20170920141949.079 RX>
CR:Ack=0:RFEBDME:R:S#=01:DCC=012:PH=19
<COM7: 20170920141949.274 TX>
rfebd 02 0
<COM7: 20170920141949.287 RX>
CR:Ack=2
<COM7: 20170920141952.277 TX>
rfebd 03 0
<COM7: 20170920141952.290 RX>
CR:Ack=2
<COM7: 20170920141955.279 TX>
rfebd 04 0
<COM7: 20170920141955.292 RX>
CR:Ack=2
<COM7: 20170920141958.281 TX>
rfebd 05 0
<COM7: 20170920141958.295 RX>
CR:Ack=2
<COM7: 20170920142001.285 TX>
rfebd 06 0
<COM7: 20170920142001.300 RX>
CR:Ack=2
<COM7: 20170920142004.287 TX>
rfgsid 01
<COM7: 20170920142004.302 RX>
CR:Ack=0:RFGSIDME:R:S#=01:DCC=001:PH=464C554B4520563330303146432C5630322E30312E303000
<COM7: 20170920142004.621 TX>
rfgus 01
<COM7: 20170920142004.644 RX>
CR:Ack=0:RFGUS
ME:R:S#=01:DCC=004:PH=56333030314643
<COM7: 20170920142004.984 TX>
rfsst 01 1479C25900000000
<COM7: 20170920142004.995 RX>
CR:Ack=0:RFSST
<COM7: 20170920142100.617 TX>
rfemd 01 1
<COM7: 20170920142100.654 RX>
CR:Ack=0:RFEMD
... now starts the interesting part, these 
... are actual measurements,
... payload seems to be at "PH"-tag. 
... They continue until rfemd 01 2 command is issued
ME:R:S#=01:DCC=010:PH=01000042020C0601
ME:R:S#=01:DCC=010:PH=00000042020C0601
ME:R:S#=01:DCC=010:PH=00000042020C0601
ME:R:S#=01:DCC=010:PH=01000042020C0601
<COM7: 20170920142116.922 TX>
rfemd 01 2
<COM7: 20170920142116.930 RX>
CR:Ack=0:RFEMDME:R:S#=01:DCC=010:PH=00000042020C0601

After looking at this, it seems that we need only to issue few commands to get it to register (and wait for a while between commands):

writeToPort("rfsm 1", 2000);
writeToPort("rfdis 1", 3000);
writeToPort("rfebd 01 0", 3000);
writeToPort("rfgsid 01", 2000);
writeToPort("rfgus 01", 2000);
writeToPort("rfemd 01 1", 2000);

Below is writeToPort-function used in above example and also other necessary  functions to get it running.

void writeToPort(string t, int delay=1000)
{
 serialPort1.WriteLine(t);
 System.Threading.Thread.Sleep(delay);
}

private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
 string reply = serialPort1.ReadExisting();
 if (reply.Contains("ME"))
 {
  string value = parseReply(reply);
  if (value != "")
    lblValue.BeginInvoke(new MethodInvoker(() => lblValue.Text = value.ToString()));
 }

}

string parseReply(string input)
{
 string val = "";

 // ME:R:S#=01:DCC=010:PH=00000042020C0601

 if (input.Contains("="))
 {
  string[] linesA = input.Split(':');

  foreach (string lineA in linesA)
  {
   string[] lines = lineA.Split('=');
   if (lines[0].Contains("PH"))
   {
     // payload ?
     try
     {
        string pl = lines[1];
        pl = pl.Replace("ME", "");
        pl = pl.Replace("\r", "");
        string lvalue = pl.Substring(0, 4);
        string msb = lvalue.Substring(2, 1) + lvalue.Substring(3, 1);
        string lsb = lvalue.Substring(0, 1) + lvalue.Substring(1, 1);
        string plusOrMinus = pl.Substring(6, 1);
        string mvOrNot = pl.Substring(pl.Length-1, 1);
        int num = int.Parse(msb + lsb, System.Globalization.NumberStyles.AllowHexSpecifier);
        if (plusOrMinus == "8" || plusOrMinus=="C")
          num = num * -1;

        if (mvOrNot=="1")
        {
          double dval = Convert.ToDouble(num) / 10.0;
          return dval.ToString();
        }
        return num.ToString();
      }
      catch (Exception ex)
      {
          return "";
      }
     }
    }
   }
   return val;
}

As you can see, pretty rudimentary and not at all complete but it get’s it done, I’m able to read Fluke Connect module output to my own software 🙂

I still need to see what kind of coding there is at the position of decimal point for example and see better positive/negative value handling – preferably understand what each byte or bit means.

For now, this simple program gets me where I want, just rudimentary readings from wireless Fluke Connect module to my own C# software. If I ever fully decode what full payload message means, I can write an new blog-post.

For now, I have found out that the first 4 characters contain  measurement value  in hex. This is the same value that is displayed in the screen of module.

I have logged few data-points to help decode this:

# mV positive 546.0 (?)
ME:R:S#=01:DCC=010:PH=54150042020C0601

# mV negative
ME:R:S#=01:DCC=010:PH=531500C2020C0601

#Volts negative -0.758
ME:R:S#=01:DCC=010:PH=F6020086020C0600

# Volts positive 0.758
ME:R:S#=01:DCC=010:PH=F6020006020C0600

# Volts positive 7.53
ME:R:S#=01:DCC=010:PH=F2020004020C8600

# Volts negative -7.53
ME:R:S#=01:DCC=010:PH=F1020084020C8600

# Just a bit over -30V, red lightning led ON
ME:R:S#=01:DCC=010:PH=B90B0084020C8620

# Just a bit under -30V, red lightning led OFF
ME:R:S#=01:DCC=010:PH=B40B0084020C8600

These have all come from Fluke Connect DC voltage module V3001 FC. I will eventually also log what 3000FC Multimeter and 3000TC temperature modules will output. But for now, this should get things going…

If you have any information or suggestions, please feel free to contact me.

Until next post, have fun!

 

It’s official – my Porsche Boxster is road legal ! It’s officially (verified from Trafi) first electric Porsche in Finland 🙂

For celebrating this, here is a short video:

Time flies by. It sure feels like so when looking back to start of my  eCagiva electric motorcycle project. In this post I mirror eCagiva-project to other aspects of our life and surely things have changed a bit since the start of this project.

I started to build eCagiva in 2009. Location was a “bomb-shelter” workshop. It really was an old bomb-shelter! Tight space with a very low ceiling. I was renting it for about 10 years before finally moving to bigger workshop (more on that later). There I had an small lathe (I converted it to CNC), an homebuild CNC-mill and few homebuild 3D printers. But no proper welding or metal working equipment. Still I managed to build few electric motorcycle conversions there. Nice memories on that first workshop 🙂

For about a year eCagiva was equipped with a custom made AC motor and a Sigmadrive AC-controller along with Cedric Lynch BMS. This was equipment it was registered with, got it street legal at 2010. After a while that custom made AC-motor gave smoke out – it overheated badly and stopped working.

This was in the middle of summer driving season. I  decided that next motor will be proven DC and contacted 2009 TTXGP-winning team Agnimotors. I got their factory repaired racing motor Agni 95R quite quickly delivered to me. I also installed Kokam 70 Ah cells, Kelly KDHE-controller and an Elithion BMS. I drove with this combination for few years and it worked nicely. For a while I had also an onboard charger, PowerFinn PAC800 (800W) but broke it after driving in rain (my fault, lack of proper water-protection…).

After hearing about nearby bargain on 7.5 kW, 2.5 ton metal lathe I had to say big YES. So I bought the big lathe even though I didn’t have enough workshop space for it… That was one of those “once in a lifetime” offerings and I really had to yes to that one. This gave an nice excuse to rent a new workshop –  bigger and with higher ceiling. Lathe was easy to move in with standard lifting truck and plenty of room for eCagiva and other projects too. This was also around the time when I quit my day-job and started to work for my own company.

Soon after moving to new workshop eCagiva got an electric friend – a Porche Boxster conversion project started when we found a nice donor-car. eCagiva worked fairly well, minor repairs here and there but mainly ok and all the time drivable.

After spending less than one year in that workshop our landlord offered nearby office/workshop-space for us to rent – more than 2x space of previous workshop for little more rent. So we rented it and got more space for our projects. Soon after that we found another electric car, Elcat van with Lithium batteries. Decided to have it since it’s perfect for testing various components. Elcat has been our daily driver ever since. We also found few electric bicycles.

eCagiva was mostly working fine. Some nuances still

• lack of on-board charger
•  

  too long chains, they kept rattling noise

• wrong location for controller (front tire bumbed to it in hard braking!)

 

In summer of 2014 I found out that one Kokam cell had  discharged to fully empty and had been destroyed by that event. I decided that this was good time to make an major overhaul on the bike.

• replace BMS with our own system
• move motor to better position
• move controller to better position
• install on-board charger
• make a better mounting for battery box

My friend Eero designed an nice 12 cell BMS-node with a CAN-bus and few other bells and whistles. I made an BMS-main unit to control those nodes and handle other things in my conversions. BMS and other components were tested in Elcat and they seemed to work really nicely.

It took a while to get that overhaul to finish – in fact one more workshop change was needed to find time for finishing the overhaul.

In 2015 summer we found an ideal solution – an house with a proper workshop.

After moving in and few months of settling down I decided to bite the bullet and finish the overhaul. Now I had a proper MIG and AC/DC TIG for welding both aluminum and steel so fabrication of parts was much easier than previously. Also I had an small metal mill and large lathe so it was fairly easy to fabricate necessary parts. I installed an water cooled 3kW Eltek Valere charger under the seat and build an water-cooling system for it. Charger is  controller via CAN-bus and I integrated all the control functions to my driving user interface, an IFM IP65 rated color display. After a “few” days worth of work on the bike it was running again. This time better than ever.

So in the summer of 2016 bike was driven more than ever and worked finally like it should. When I look back, it certainly seems that it took few iterations to get it right. Now it’s beginning to feel fairly good. I wonder how the Boxster project will be, do I need to do few iterations on that also …

Still some minor adjustments could be done for the bike – such as making more stable 12V. I think DC/DC is strugling to power everything since it sometimes shuts off. Most likely I’ll add an small 12v lithium-battery in parallel to DC/DC converter for better 12V voltage stability.

Here is an video of the eCagiva as of 2016.

That’s all for now, thanks for reading and have a nice time building your own way forward !

It’s been a long time since last updating this blog.

Quite a bit has happened in the meantime –  we bought an house, workshop has been moved, got a bigger solar panel array etc.

Biggest thing is that finally I have my very own workshop in my yard. Nice big doors so I’m able to move bigger projects in and out easily. Can’t say enough how much this has changed the way I do things – I’m able to visit workshop for just 10 minutes if needed. Previously it was always about 10 kilometers (one-way) trip to workshop. So visits tended to last longer than 10 minutes and had to be “planned” a bit beforehand because of that.

Now, it’s just a matter of walking of about 10 meters from our front door, doing some minor or bigger work and getting back to house when ever it feels like so!

This has been a dream of mine since childhood – to have proper tools and workshop at home 🙂 Finally managed to have it happen – JIIHAA 🙂

Personal projects have flourished – this year I have managed to

1) get water-cooled 3 kW CAN-charger installed to eCagiva e-motorcycle and have eCagiva motor moved about 10 centimeters backwards and controller moved few centimeters downward. This has helped a lot for handling of the bike.

1) convert an 1.2 kW full suspension electric bike to fully working condition. It spins wheel quite nicely but still needs some minor work to be done.

3) have my electric Porsche Boxster conversion finally moving !

Here is the very first driving out of my workshop – I know, hood needs proper cleanup after sitting few years. But still, it’s moving 🙂

It took a lot longer than expected but finally I managed to get it moving. No big battery pack yet, just a small pack in the trunk. Mainly to move it around workshop. Next up front trunk battery box wiring. And all the other little bits and pieces.

 

 

 

I have recently tested whether Raspberry Pi is a good DIY solution for electric car UI computer. It seems to work well – it has been in use for a few days now and it seems to run fairly smoothly. Here is the basic schematic of the system:

So Raspberry Pi is equipped with an CAN-bus shield and an wlan dongle. I compiled a custom kernel that supports both of these devices and wrote a very simple Python script to read values and pass them to web UI. CAN bus has new messages from shunt every 250ms and from BMS every 1 sec so update rate will not be so quick. I’m confident that RPi can easily handle all this. I’m using Arch-Linux as it seems to work quickly and nicely with Pi. I keep my Raspberry PI always powered on as it doesn’t really use much energy (only few watts) and I have about 23kWh battery. Raspberry Pi creates an Ad-Hoc WLAN around the car so I can easily connect to it. I’m most likely going to replace that with a proper WLAN router though (since Ad-Hoc doesn’t seem to support WPA2 encryption which I would very much like to have).

For powering the Pi, I just made an 5v PSU from stock “car usb-power adapter” and enclosed it with a Pi to a plastic box.

Here is a picture of the box:

Not pretty but hey, it’s a 1st prototype 🙂

In the CAN-bus there are 3 devices: 1) Raspberry Pi, 2) Isabelle Huette “intelligent” current-shunt and 3) few of our own BMS-boards. So when everything is up and running, I’ll be able to read and control all these devices from a mobile phone. For now, I’m only testing the system with traction pack current. But as this already works, it should be fairly easy to read and  display all the other important values as well (such as min/max cell voltages and -temperatures etc.). I’m thinking about adding an USB-HDD to RPi because I want an database for storing all that data for later viewing and analysing. And I have read that database writes could quickly render my main SD-card useless so I’m going to keep my MySQL data-partition on separate HDD-drive.

For now, the display only consists one simple gauge (justgage.com) displaying traction pack current but rest of this setup should be fairly simple – just add some more UI-software for other values as well. You can see how my 1st working setup actually works from this small video:

The source code is not yet ready for “prime-time” but eventually this all will most likely be Open Source. For now, this is all I have – I’ll post more when I update the display and get those BMS boards also to display some values on my phone.

We decided to invest in a small solar power plant. We have only 2kW worth of panels but that should be more than enough to cover our daily drivings with Elcat, eCagiva and Porsche.

I bought some wood for mounting the panels. Elcat-EV was handy for towing the woods to our workshop.

After few days of installation and building we had a nice array of 8x250W panels installed.

What remains to be done is connecting the Sunny Boy 3000TL-21 to grid and start using this array. That is planned to happen next week. Also as inverter has a Bluetooth connection, we can make an live tracking of power generation.

We had a need for a small BMS system for FlyNano electric airplane. We didn’t find any existing system that would suit for our needs. So we decided to roll our own system.

Design goals were

• Small weight
• Proven measurement technology
• CAN-bus
• Minimal power draw from cells
• Suitable connectors for 6S and 5S LiPo-packs

Based on these goals we settled on using LTC6803-4 BMS-IC along with Atmega64M1 microprocessor. With these goals in mind Eero Vuorinen designed an PCB and we have build first prototype batch of these boards.

Each board can handle 4-12 cells and has an isolated CAN-interface along with 8 Mbit of eeprom-memory for storing cell-voltages etc. Also power is controlled via isolated DC/DC converter so almost whole board can be powered off when not in use. Here is a picture of almost bare PCB with only LTC and Atmega soldered:

That’s 2-sided PCB with about 150 SMD-components on each side.

Now we have about 5 of these boards up and running with basic software capable of measuring cell voltages and sending them to CAN-bus. First tests have been made to test whether LTC<->ATMEGA SPI bus functions without any level-converter between them and whether it works also in noisy environments. For that we have made an basic test-setup consisting of Dynaload variable 4 kW load, Powerfinn 0-120V charger, an National Instruments USB6251 BNC DAQ card with Measurement Studio along with some custom C# software for making some basic measurements. Here is the current schematic for our bare-bones BMS testing setup:

Temperature measurements are missing from above diagram, those are also planned but not yet implemented. With this setup we are able to test either manual tests or make some more automated tests in the future. For now, we have tested that the SPI bus seems to work with quite big current pulses also.

So far highest peak to peak current values have been about 120A with about 5 kHz frequency and current pulsing between 0 – 120A. We also did about 40A peak-peak with frequencies up to 20 kHz. With this kind of frequencies the A123 M1 test cells seem to warm up very quickly. They might be destroyed if we keep this test going for too long but as this is mainly about wheter or not our new BMS-boards work in noisy bench-environments, it is not so big deal if we destroy a cell or two – provided that we get the results we need to proceed our BMS implementation.

For now, we have 11 pcs PCB’s and parts for 12 boards so we could cover about 132 cells with these boards. But as these are “0-batch” boars there are already some issues to be fixed in “1.0 – batch”.

Here are few shots from latest measurement sessions:

60A peak-to-peak, 1.2 kHz

In the picture above we have a oscilloscope connected to a Fluke i310s current-clamp. We are measuring both peak-to-peak, RMS and frequency of our current spikes. Purpose of this test was to see if SPI communication works in noisy environment too. These kind of load-spikes could generate some noise on our measurement circuits and it would be nice to be able to reproduce some of that actual noisy EV-environment with our bench testing before we install these to any actual vehicle.

BMS-node along with A123M1 cells on left with current clamp connected to scope

Here we have actual measurement setup. Small module of A123 M1 cells on the left along with a BMS node and a current clamp connected to a scope. That massive thing below oscilloscope is Dynaload variable load capable of generating 0-600A / 0-400V / 0-4 kW DC-load up to 20 kHz frequencies. And few important safety issues – cells are on the table that has wheels – just in case it needs to be rolled outside quickly. Testing station is located so that is only about 2-3 meters from the large doors for easy emergency “eject” of the cells under test. Under table there are large cutters capable of cutting easily up to 100 mm2 cable for quick disconnecting the cells. Also safety goggles are needed whenever testing these cells – they are easily capable of making very big sparks if accidentaly short-circuited.

Small program running on Atmel and continously testing SPI-communication between LTC and Atmel

Here is a small software running on Atmel ATMEGA64M1 processor and communicating with a normal laptop with just a RS232 port. It continously scans for commucation errors between LTC and Atmel. So far we have not been able to generate any errors while testing different frequencies and currents up to 120A. That current is quite small for any serious EV-use but as our test cells are just 2.3Ah cells they are already screaming “help” with about 50C discharge spikes hitting on them with about 5 kHz frequency 🙂 I don’t know if anyone has connected a scope along with a current clamp to any EV while driving on highway. It would be interesting to know if high frequency peak-to-peak values are above 120A. We will eventually know this for sure but for now, this is all we needed to test from SPI. Now we have moved on to test a battery with 3 nodes with 5/6/6 cells configuration so total 17 cells on that test. As each node can have up to 12 cells and there can be 16 nodes on same bus with this hardware it totals to 192 cells in the largest possible battery with this system.

It’s been really nice to have few free days off from work and have some easter fun with family. We decided to finish our electric go-kart project that has been waiting for inspiration for many months. Snow is starting to melt and workshop front yard has an asphalt covering already visible – so it’s ready for kids to drive with their car.

Yesterday we got the kart moving by just connecting some 12V UPS batteries with 2S2P configuration directly to motor. Motor is a small motor from Chinice “pit” scooter that I got as a gift from a friend. Scooter was not usable but motor seems to be – it’s underrated and not much torque but just fine for kids go-kart (for now at least). I had to run behind kids while they drove and stop the car if needed since there was no on/off switch and/or speed-pedal but it was fun anyway 🙂 (Btw, it was safe because car moves about walking speed and does not have much torque so they couldn’t move far from me).

Today I milled an spring-loaded on/off speed-pedal from aluminum and connected it to 24V contactor. It made driving much more ejoyable for both kids and parents 🙂 So finally kart is drivable and only major thing left to do is some cleanups on connections and decide if we should keep it with Lead-batteries… Or switch to some more powerful A123’s that I happen to have lying around at workshop… (And more powerful motor etc. etc.)

 

PS. It’s a good thing that my friend has brought his 90 kW+ electric go-kart project to our workshop… So I don’t really have to dream going big with this car. This car can stay as a slow kid-friendly workshop-car and we adults can drive with that 90+ kW go-kart (when it’s finished, that is…)  🙂

 

Motor controller arrived, along with an EMC – package from Rebbl. I must admit that Solition 1 is an impressive piece of equipment. Here is size-comparison between Unitek Bamo D3 AC-controller and Soliton 1:

 

Bamo can work up to about 600V and output about 300A (if I remember specs correctly). And Soliton 1 works up to 340V and outputs 1000A. That should be plenty of power to any street car – in fact it will surely melt my Kostov Alpha 11″ 250V if I could apply full power for more than few seconds. Along with an EMC-package came few meters 120 mm2 and 70 mm2 shielded cable. No connectors, need to obtain those as well.

I should order batteries soon. These are my current calculations;

 

(consumption from diyelectriccar.com)	291	wh/mile
	181	wh/km
	3,2	vpc nom
	3,65	vpc chg
	3,4	kg pc
	100	Ah pc
	101	eur/pc / VAT 0%
	5,4	cargo/pc / VAT 0%
pcs	70,0	80,0	93,0
chg	255,5	292,0	339,5
nom	224,0	256,0	297,6
kg	238,0	272,0	316,2
cap	22400,0	25600,0	29760,0
range, km 100%	123,8	141,4	164,4
range, km 80%	99,0	113,1	131,5
price	7070	8080	9393
cargo	378	432	502,2
total	7448	8512	9895,2

 

I think I go with 80 cells for my first setup. That could theretically give me about 140 km maximum range (100% DOD) and still be somewhat reasonable weight. Of course it also depends if I can’t really get all those cells fit to a car. But for starting point this  should be ok.