[Ovmsdev] OVMS CAN-USB Call for Assistance
gipmad at gmail.com
Fri Sep 6 15:52:13 HKT 2013
Just a quick request: there should be enough space on the pcb to add a
bluetooth module. Please add at least the footprint for
This would add the need for an independent power supply, but as I
recall you were already planning to place the footprints on the pcb.
I found myself in need for a wireless connection a lot of times,
usually to get a quick log with my phone. For example, this weekend
I'm doing a few tests with a tesla model s and I'd love a more stealth
method to get the data.
About being stealth, I found myself using ELM327 adapters to get CAN
data more than a few times, but I have to include a lot of filtering
due to the slowness of the adapter. That said, the STN1170 is an
"elm327 on steroids", and may have enough horsepower to log unfiltered
can data, while being a very good diagnostic tool to interface with
I still have not tested it, but maybe will soon. Single chips are
available for 10$ in single quantities.
2013/9/5 HONDA S-2000 <s2000 at sounds.wa.com>:
> 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
> 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
> Does the CAN spec (ISO-11898) say what the required precision is for the
> 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.
> 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
>> 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
>> 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
More information about the OvmsDev