Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Neuer_User]

Have you seen these CAN bus isolators:
http://www.peak-system.com/PCAN-Optoadapter.215.0.html?&L=1
Maybe that could be the easiest way. But they cost 75€, so probably more expensive. But seems to me to be the easiest solution.

[Neuer_User]

Great investigation Lenny. Good to know. In the meantime I testted a lot together with Remmie, who is the absolute codemaster behind this all. He added a so called PID regulation to the Leonardo code, wich solved the problem of uncontrolable current when having a low state of charge. On my double flatpack 2000 and on his quadpack S this is now kind of working. But still tweaking though.

We're getting so close to a perfect controllable QuadEltekSupercharger 

This QuadEltekSupercharger you can now hook up to:
1 phase 16A (get as much from one single plug) : onboard + 2x10A = ~3,5 kW
3 phase 16A (get as much from one mennekes 11 kW station) : onboard + 2x30A = ~ 7,9kW
3 phase 32A (get as much from one mennekes 22kW station) : onboard + 4x1800W (full power) = ~8,5 kW

And, of course the
1 phase 6A (for example the socket on the capsite) : onboard only = ~1,3 kW

The charger is controlled with one pushbutton to set the current, starting with the 10A setting. A display shows Current Temps etc, see previous post. Now you can really charge everywhere and use the local power situation to the max. No matter what.  Soo cool

Just to understand: With the current ("published") implementation, the voltage is only regulated on one flatpak. Therefore, the PID can regulate it between 43.5+57.6=101.1V and 57.6+57.6=115.2V, correct?

So, if the battery voltage is below 101.1V, then the current solution cannot regulate the current by reducing the output voltage anymore. So, the flatpaks will draw the maximum current they can get and work with. Correct?

In the future solution (that you are developing), you would have both flatpacks regulated, so the minumum voltage would be 43.5+43.5=87V, so below the lowest expectable battery voltage. So, the PID should be able to adapt the output voltage to whatever is needed for the indended current. Correct?

[wijnand71]

Yes, all true on all points

[Neuer_User]

Have you seen these CAN bus isolators:
http://www.peak-system.com/PCAN-Optoadapter.215.0.html?&L=1
Maybe that could be the easiest way. But they cost 75€, so probably more expensive. But seems to me to be the easiest solution.

@wijmand71: And what about this CAN bus isolator? Could that not be the much easier way? Just attach put it between the Leonardo and the second flatpak. Then the one Leonardo should be able to control both flatpaks. Or am I missing something?

[remmie]

It not that simple, the Leonardo has more than enough digital pins available even with the OLED, and SMS pins used.

However, the CANbus transceiver uses the MOSI, MISO and SCLK pins of the arduino. thusfar we have not investigated if you cannot connect multiple CAN transceivers on those pins (likely not) or if we could use other pins and use a software CAN solution. My arduino skills don't go that far (yet).

The easiest thing for us now was using two Leonardo boards and send the PID over to one another via I2C, that only adds 4 lines to the code.

We will definitely investigate if everything can be done using only 1 Leonardo board and an isolated can board.

[Fred]

You can definitely have more than one SPI device attached. That's what the CS line is for. I'm slowly getting round to playing around with my flatpacks, but lots of other stuff getting in my way. I absolutely refuse to use an Arduino though - I can't stand them.

[Neuer_User]

I think to clarify the options that generally exists, here is a short summary:

Solution approach 1: Two arduinos, aligning on PID via some serial interface (e.g. I2C), isolated between each other. They thus would need separate PSUs, too. (see attachment 1)
Pros: probably cheapest solution
Cons: many components, more complex program, more cabeling, more space

Solution approach 2: One arduino, one additional isolated CAN bus transceiver, such as LTM2889 (see attachment 2)
Pros: Many different CAN bus tranceivers can be used.
Cons: PCB needed for the transceivers, additional programming for the arduino

Solution approach 3: One arduino, one CAN bus isolator (see attachment 3)
Pros: simple solution, only one additional part (ready for use)
Cons: only few products on the market, and mostly rather more expensive (>= 75 €)

[hubert]

I absolutely refuse to use an Arduino though - I can't stand them.

Sounds like an emotional issue... Do you prefer a PIC structure?

[MrDude_1]

I absolutely refuse to use an Arduino though - I can't stand them.

Sounds like an emotional issue... Do you prefer a PIC structure?

I was a diehard PIC microcontroller user until I broke down to the AVR microcontrollers...  the Arduino and its library eventually snagged me for its ease of use for quick projects.  at this point, I use a mini/micro clone for just about everything.

[Doug S]

I was a diehard PIC microcontroller user until I broke down to the AVR microcontrollers...  the Arduino and its library eventually snagged me for its ease of use for quick projects.  at this point, I use a mini/micro clone for just about everything.

Lol I'm exactly the opposite. I've used AVRs, MSP430s, Arduinos, Raspberry Pis, Fez, and everything else you can think of, but my first and still favorite platform is the Microchip PICs. I can't STAND under-performing, pre-digested solutions like you find on the Arduinos. They use ten times the resources and do things ten times slower than they should. In terms of bang for the buck, I remain convinced that the PIC platform can't be beaten.

I'm also not a big fan of throwing a BeagleBone in every product. I have nothing against BeagleBone (or any other embedded LINUX solution), but I think it's a lot more power than just about anybody needs or winds up using. OS'es are cool in their place, but they do consume a tremendous amount of resources and place a burden that most people just don't need and shouldn't be burdening themselves with. And they STILL can't handle real-time apps very well! By comparison, it's insane what an 8-bit processor with 128k flash RAM can be made to do, with many parts under $3.00 OTC, in small quantities.

[Fred]

I probably should have said nothing, as I don't want to drag a useful thread off topic. The reason I dislike the Arduino is because of the awful development environment, sloppy, bloated code and lack of proper JTAG debugging. It also seems to foster the sort of thinking that relies entirely on buying a "shield" downloading somebody else's library, and writing a single if statement.

I'm far happier with almost any other microcontroller and IDE, normally MSP430, STM32, TI's Tiva or CC ARM devices, etc.

Anyway, that's just my personal opinion. Let's not detract from this excellent work on Flatpack-based charging.

[togo]

You can definitely have more than one SPI device attached. That's what the CS line is for. I'm slowly getting round to playing around with my flatpacks, but lots of other stuff getting in my way. I absolutely refuse to use an Arduino though - I can't stand them.

Maybe a getchip.com is for you.

https://bbs.nextthing.co/t/can-bus-mcp2515-via-spi-anyone/11388

[remmie]

If you're not into arduino you could also use this DUAL PICAN board and a raspberry PI.
If you would also connect that to the OBD port of the zero and add a (say) 5" (preferably waterproof) touchscreen monitor. someone could make an awesome interface for the Zeroes.

http://skpang.co.uk/catalog/pican2-duo-isolated-canbus-board-for-raspberry-pi-23-p-1482:b3bde05466bb8177b513f31d07dc4947.html

And get a display like the energica's

[Fred]

I'm OK with the microcontrollers I already use, thanks. Both the chip and the Pi are a little OTT for some simple SPI/CAN communication.

[togo]

I'm OK with the microcontrollers I already use, thanks. Both the chip and the Pi are a little OTT for some simple SPI/CAN communication.

Yeah, I missed the linux-based dealbreaker comment.  Shouldn't have said anything.  The canbus seemed relevant but you'd already identified that chip too.