Paul and Sabrina's Cheap 3 Phase Inverter (AC Controller) with Field Oriented Control

[e*clipse]

Originally Posted by MPaulHolmes

I've never used a memory card before. I've seen the code though. It's not a small thing to include, in terms of software, from what I've seen. It would be very nice though.

I don't have any handshaking or who knows what with the rs-232 serial. Would there be anything special involved in adding one of those bluetooth interfaces? Or is it just as simple as connecting the ground, tx, and rx to the input of the bluetooth, and then the phone or whatever magically receives the data? So, is this all you do?

cell phone --- $5 bluetooth thing --- rx, tx, ground on control board.

It doesn't look like setting up an SD card is a big deal. Basically, it can be done with the SPI port, which is an synchronous serial connection. I used this interface w/ a 18 series pic some years ago for my 1st gen BMS.

The only trick seems to be a 5V > 3.6V level shift, which is done with a hex converter. Here's the circuit for the SD shield. The only stuff that matters is the SPI connection from the Arduino, the level shift, and the SD card. All these are on the top of the schematic. NBD.
https://cdn.sparkfun.com/datasheets/...Shield_v14.pdf

The code for it looks pretty reasonable as well. Here's the Arduino C code for an SD card data logger:
https://github.com/sparkfun/microSD_...Datalogger.ino

- E*clipse

[MPaulHolmes]

Wow they have come a long way since I looked at interfacing to a memory card. There was a ton of assembly language, and special sequences of things to guarantee a proper data read (like with the EE Prom). And constructing a model of the FAT on the card. And a bunch of memory copy routines. This doesn't look bad at all.

[e*clipse]

Originally Posted by MPaulHolmes

Wow they have come a long way since I looked at interfacing to a memory card. There was a ton of assembly language, and special sequences of things to guarantee a proper data read (like with the EE Prom). And constructing a model of the FAT on the card. And a bunch of memory copy routines. This doesn't look bad at all.

Oh gawd, I remember that.... Yeah, that's why I stayed away from EEprom.

There is a tutorial about formatting the SD card. It looks like normal memory formatting procedures. Personally, I haven't done that with any of my camera's cards and they seem to work just fine in my Macs, PCs, and Linux machines; kind of like USB memory sticks just work. A few years ago I remember having to format those for specific computers.

I think what I'm going to do is buy two of those Spark Fun CAN bus boards, the one with an SD card connector. They can connect to a couple of Linduinos I have for the BMS. With this I can mess with CAN and data logging with an SD card.

- E*clipse

[Thalass]

Originally Posted by e*clipse

With all the work you guys are doing with the data, I started thinking a bit about how to do this with the CAN bus.

It's really nice that you can stream data using standard serial data; that could be very useful in the future; not only for debugging.

Actually, the CAN bus really isn't a big deal; is mostly a communication protocol. There a quite a few requirements for meeting the protocol - actually more than the hardware requirements...

I think it would be nice to use the CAN/OBDII protocol for the communication - that way external devices could be used for monitoring, etc.

The main part of the protocol is pretty easy - there are two versions. The "standard" frame uses an 11 bit identifier and the "extended" frame uses a 29 bit identifier. Both frames can transmit up to 8 bytes of data.

All the other stuff, including bits that communicate message priority, a CRC check, etc are the same. The bus speed is somewhat adjustable, with the main tradeoff being noise immunity and processor time for high bus speeds.

The main problem is that outside the government regulated indentifiers, there is very little information about the identifier. Since the protocol was originally design for pollution control, there is nothing I can find about EV stuff.

For example, EVTV has those nice Andromeda interfaces that display a lot of useful EV stuff, all transmitted by CAN. However I can't find anything about which indentifiers they use.

It sure would be nice to come up with a set of identifiers that would be useful for EV's and readable by any CAN bus / OBDII scanner.

Thoughts?

- E*clipse

This is the kind of thing that has had me restricting my EV conversion fantasies to older cars. Newer cars would pitch a fit if the ECU was suddenly missing.

[Thalass]

Originally Posted by MPaulHolmes

Once it is initialized CAN is very easy to use. You can set up each node to ignore or accept whatever types of messages you want. Then, everybody just willy nilly blasts whatever the crap they want with no regard to concern about collisions. And they just accept whatever messages are for them. I have used it between a charger and several bms boards. Each board sent a packet of 8 bytes long, which were the 8 voltages of that bms module's 8 batteries. There were 6 modules just blasting their 8 bytes randomly and each ignored each others 8 bytes. The charger would pick up all the packets. No problems with noise and no missed packets (i dont think). And the data was never corrupted. You just use a little 8 pin $1 part along with the dspic CAN module.

Sounds a bit like MQTT, which I've been using for a home automation project. Though MQTT needs a central broker to receive published messages from devices and to distribute them to subscribed devices. So probably not that close now that I think about it. >.<

[freebeard]

EVTV Motor Verks Store:CAN Tools

Notice:

• EVTV Motor Verks Store: 1 CANKIT - CANbus kit with Microcontroller and Cable, CAN Tools, ArduinoDueCANBUS
• EVTV Motor Verks Store: EVTVDue Microcontroller, CAN Tools, EVTVDue2
• EVTV Motor Verks Store: 2. Dual Channel CAN bus Shield for Arduino Due, CAN Tools, DueCANBUS

Car Hacker's Handbook is an extensible overview of in-vehicle security.

[P-hack]

Originally Posted by e*clipse

For example, EVTV has those nice Andromeda interfaces that display a lot of useful EV stuff, all transmitted by CAN.

Well the tesla uses a linux tablet, and you can get one for like $50 with bluetooth/gps/wifi/sd slot/google maps/4g/usb (ssd?)/phone integration/stereo sound/ attach rearview camera/etc. etc. etc.

and this is the "cheap" 3 phase controller thread. A $700 proprietary display and hundreds in can adapters isn't terribly in line with that goal. A sd adapter, or a bluetooth adapter for realtime information/graphs, certainly would be.

Either way the controller needs to emit the data, but otherwise you would want the controller to be fairly stand-alone. I wouldn't add obd as a requirement certainly, and can for cans sake doesn't make a lot of sense. It has a "coupling" effect which will bind up progress, where you probably need a de-coupling.

[freebeard]

An hundred dollar Arduino board isn't onerous as a development tool.

The $50 Amazon Fire is much similar to my Barnes & Noble Nook Color, a media consumption tool. The Nook can run Cyanogenmod (Android) from it's SD card. If the Fire can do that maybe you'd have something.

[P-hack]

Originally Posted by freebeard

If the Fire can do that maybe you'd have something.

there are thousands of tablets out there that run android already though...
Amazon.com: android tablet bluetooth gps - Feature Keywords: 4 selected / Android / Tablets ...: Electronics

plus mixing in yet another microcontroller platform doesn't thrill me.

[Piotrsko]

Yes but unless jailbroke (rooted w custom OS) Fire notebook is incredibly stupid. I have one.