[Ovmsdev] OVMS CAN-USB Call for Assistance

Tue Sep 10 09:18:07 HKT 2013

That is a neat idea, and I've seen some battery-backup circuits work this way.

So, we take the car +12V through an IN4007, the USB +5V through another IN4007, join the outputs from the diodes (presumably with a 100uF capacitor to ground to give us some breathing room during power supply switch), and use that as the input to our LP2992 (or equivalent)? The GND from both car and USB would be connected together.

No need for a switch - whichever source has greater voltage will win (so, normally, car +12V when connected, and USB +5V when not).

We can use a fixed 3.3V regulator, and the SN65HVD235 transceiver, to keep everything at 3.3V.

The circuit comes down to 1xLP2992 for 3.3V power, 2xSN65HVD235 for CAN, 1xMCU(3.3V), DB9 & USB connectors, ICSP pins (for emergency), expansion pins (arranged for optional bluetooth module), and a few passives. That is neat.

Now, what would be truly amazing is if we could fit an SD-CARD in this, as it would allow for unattended logging without RAM limitations (and in particular what happens to that RAM when you unplug). The circuit components are minimal (a socket plus a few resistors), and firmware is easy, but I am worried about the housing/casing. Or, perhaps, micro SD just on the motherboard (and use serial-USB commands to replay and do other file management commands)? Can you imagine a little handheld device you just plug in the car, press a button, and it starts recording to SD - then pull it, plug into your laptop and hit 'playback'? Pretty neat.

Anything else?

Regards, Mark.

On 9 Sep, 2013, at 11:25 PM, Mastro Gippo <gipmad at gmail.com> wrote:

> After a quick search I found this:
> http://www.ti.com/product/lp2992
> with a vdo of less than 450mV and a max input voltage of 16V, it may allow us to just use 2 diodes to auto-select the highest power source. Maybe a similar product can be found on the china market with similar features but cheaper.
> The switch idea is good too, but a bit less practical IMHO.
> Regards
> MG
> 
> 
> 2013/9/9 Mark Webb-Johnson <mark at webb-johnson.net>
> 
> I'm working on a rough eagle sketch based on the UWB32 as a starting point. Just something to get a pricing indication and that we can then see how other design could compare. It is a very simple circuit.
> 
> 3x LEDs - 1 red, 1 green, 1 blue (power). 1 push-switch to be held down on plug-in to put the unit into firmware-update mode.
> 
> I'm asking the factory for costing for 2 CAN ports. Extra cost looks to be about US$1-US$2 for the extra port, but it may be worth it. It does allow some pretty neat bridging tricks, as well as increases the flexibility of logging. It can be done with a single extra can transceiver chip that doesn't take much space (8 pin IC only), and we can use already spare pins on the DB9.
> 
> The UWB32 approach is to use a LM317 style voltage regulator, to take the 5V USB to 3.3V. But, if we're going to add pinouts for bluetooth / expansion / whatever, and with the previous discussion regarding power from the 12V car side, I thought it worthwhile investigating if there is a simple way of doing this from a selectable power source.
> 
> Here is the simple UWB32 style circuit for 5V USB -> 3.3V, that I currently have in my design:
> 
> The UWB32 has a separate LM317 and selection switch, for 7.6V-15V, using this circuit:
> 
> 
> Seems to be the UWB32 is using two LM317 - one for between 7.6V and 15V going down to 5V, and then another to convert the 5V (USB or stepped down from 7.6V-15V) to 3.3V.
> 
> It seems overly complicated, but I see the issue with finding something cheap and simple to operate over the range (4.75V-15V) that we require. Most of the designs I have seen use dual LM317 (or something like it).
> 
> Anyone seen anything simple so that we could have 12V car (say 9V-15V) and 5V (4.75V-5.25V according to spec) USB go to a slide switch to select source, then a 4.75V-15V step down to stable 3.3V? Have the switch on the side - slide it towards the DB9 for car power, or towards 5V for USB power (but never both). It would be a pretty neat solution and allow for unattended logging. This is, of course, assuming we use SN65HVD235 to avoid the need for 5V anywhere on the board.
> 
> Regards, Mark.
> 
> On 5 Sep, 2013, at 10:47 AM, HONDA S-2000 <s2000 at sounds.wa.com> wrote:
> 
>> I like the MCP2551, but I don't think it's guaranteed to work without a 5V boost regulator. The USB specifications are clear that the 4.5V minimum needed is not always guaranteed to be present.
>> 
>> As for the crystal, it's all about the accuracy of the internal oscillator. USB calls out a precision in the specification, and as long as you meet that you're fine. Older chips had an internal oscillator that was not precise enough. This newer PIC32MX796 has a 0.9% oscillator, meaning that it's plenty accurate enough for USB. I trust Microchip, in that they don't claim their internal oscillator will work for chips that can't do it, but this one can.
>> 
>> That said, there's nothing wrong with putting the traces on the board (other than the space they take up). I'm partial to smaller SMD parts like the ECS ECS-120-20-30B-DU, but those are more expensive than the large canned crystals.
>> 
>> Does the CAN spec (ISO-11898) say what the required precision is for the clock?
>> 
>> The SN65HVD235 has a bus listen-only feature that seems like a really safe option for a project like this. I imagine that the device will mostly be listening to CAN messages and not attempting to inject potentially dangerous messages into an unknown vehicle. Supposedly, the listen feature also helps with autobaud.
>> 
>> Brian
>> 
>> 
>> On Sep 4, 2013, at 19:22, Mark Webb-Johnson wrote:
>>> Looking at the wholesale pricing, and given that we have 5V already and lots of experience with MCP2551, I think I'll stick with that for the initial design and then see what the factory says.
>>> 
>>> At the moment, I'm trying to make a rough design using PIC32MX795F512H+MCP2551 - DB9 at one end, USB at the other. No final decision on microcontroller yet, but I just want to get something to the factory to firm up estimates on what this is going to cost. I'll tell the factory that the SN65HVD233 is an option for them, if it is easier/cheaper.
>>> 
>>> The PIC32 is completely overkill for this, and will most likely be 50% of the BOM cost. But, I really want lots of RAM on this thing. If we drop RAM requirement to 64KB, we can save a few bucks, but it really doesn't seem worthwhile.
>>> 
>>> Regarding the oscillator, every design I've ever done uses an external oscillator. I know the PICs (and others now) have internal FSCs, but am concerned about timing accuracies for CAN and USB. The data sheet says the internal FSC can be used for USB (and incidentally is always used for 48MHz USB when in suspend mode). Anyone have any experience with this? My gut feeling is to wire the board for an 8MHz external crystal (and two caps), and then see if we can get it working reliably with that disabled. If we end up not needing it, we can leave it unpopulated at manufacture time (saving a buck).
>>> 
>>> Regards, Mark.
>>> 
>>> On 5 Sep, 2013, at 4:01 AM, HONDA S-2000 <s2000 at sounds.wa.com> wrote:
>>>> The MCP2551 requires a minimum Vdd of 4.5V to ensure ISO-11898 specifications, but USB Vbus is only guaranteed to be 4.01V under certain conditions like at the end of a bus-powered hub.
>>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130910/20bc7a19/attachment.htm>