[Ovmsdev] OVMS CAN-USB Call for Assistance

Rolf Welde Skeie rwskeie at gmail.com
Tue Sep 10 23:31:15 HKT 2013


Don't get me started.. :)
Yes, I would like to let the one mobile connection be made available as 
a wifi access point as well, a lot of new cars seems to get this now, 
with an included N-year service plan.
So yes, it would make sense in some respects.
Syncing up media servers, downloading maps, etc...
But one has to ask oneself if OVMS is supposed to take on this role, or 
if this is a different product altogether.
I would like to see the OVMS as a communication device enabling access 
across all these protocols (CAN, GPRS/LTE/++, Bluetooth, Wifi).
It will open up a whole new set of clients and interfaces of which the 
OVMS could be the "hub", it could be the core of a whole ecosystem.

Regards, Rolf

On 09.09.2013 16:00, Mark Webb-Johnson wrote:
> Rolf,
>
> What about wifi? Any use? (for OVMS).
>
> Regards, Mark.
>
> On 9 Sep, 2013, at 9:56 PM, Rolf Welde Skeie <rwskeie at gmail.com> wrote:
>
>> Mark,
>>
>> Sorry for not being clear on this, I meant OVMS.
>>
>> Rolf
>>
>> On 09.09.2013 15:52, Mark Webb-Johnson wrote:
>>> Rolf,
>>>
>>> Do you mean to OVMS or CAN-USB? For the next iteration of OVMS hardware, I understand and thoroughly agree (apart from anything, I want it for my Parrot Asteroid), but not so sure about for the CAN-USB project.
>>>
>>> Regards, Mark.
>>>
>>> On 9 Sep, 2013, at 9:48 PM, Rolf Welde Skeie <rwskeie at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Just wanted to put my vote for adding an interface like bluetooth to the OVMS. There are several devices like phones and pads which may enjoy simple wireless access to the data available through the OVMS.
>>>> One could also envision that a more sophisticated "carputer" would want to have network access through the cellular data in the OVMS.
>>>> The mobile networks' data rates are increasing and prices falling, so one might even consider sharing a high speed connection if the OVMS could sustain this.
>>>> Don't get me wrong, I do see an advantage to using the KISS methodology in this project, but just open it up a little by having a simple interface like bluetooth.
>>>>
>>>> Best regards
>>>>   Rolf
>>>>
>>>>
>>>> On 07.09.2013 14:43, Mark Webb-Johnson wrote:
>>>>> I'll try . It'll depend on space in the housing. I've got a few I've
>>>>> been playing with.
>>>>>
>>>>> I like the ones that direct solder:
>>>>>
>>>>>     http://www.fasttech.com/products/0/10004051/1292002-ti-cc2540-bluetooth-40-ble-2540-transparent-serial
>>>>>     http://www.fasttech.com/products/0/10003385/1251502-jy-mcu-hc-06-bluetooth-transceiver-serial-communic
>>>>>
>>>>>
>>>>> But the plug-in ones may be better suited as they can be entirely optional:
>>>>>
>>>>>     http://www.fasttech.com/products/0/10001791/1129201-jy-mcu-hc-06-bluetooth-wireless-serial-port-module
>>>>>
>>>>>
>>>>> Regards, Mark.
>>>>>
>>>>> On 6 Sep, 2013, at 3:52 PM, Mastro Gippo <gipmad at gmail.com
>>>>> <mailto:gipmad at gmail.com>> wrote:
>>>>>
>>>>>> Just a quick request: there should be enough space on the pcb to add a
>>>>>> bluetooth module. Please add at least the footprint for
>>>>>> [http://www.ebay.it/sch/i.html?_odkw=hc-05&_sop=15&_osacat=0&_from=R40&LH_PrefLoc=2&_trksid=p2045573.m570.l1313&_nkw=hc-05+-74hc05&_sacat=0]
>>>>>> 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
>>>>>> Torque. http://batman.homelinux.com/blog/stn1170-bluetooth-obdii-adapter/
>>>>>> I still have not tested it, but maybe will soon. Single chips are
>>>>>> available for 10$ in single quantities.
>>>>>>
>>>>>> Regards
>>>>>> MG
>>>>>>
>>>>>>
>>>>>> 2013/9/5 HONDA S-2000 <s2000 at sounds.wa.com <mailto: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
>>>>>>> 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
>>>>>>>> <mailto: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 <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.teslaclub.hk <mailto: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
>>>>>
>>>>
>>>> --
>>>> Rolf Welde Skeie
>>>> Solåsen 27, 5223 Nesttun, Norway
>>>> +47 92403016 / rwskeie at gmail.com
>>>> _______________________________________________
>>>> 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
>>>
>>
>> --
>> Rolf Welde Skeie
>> Solåsen 27, 5223 Nesttun, Norway
>> +47 92403016 / rwskeie at gmail.com
>> _______________________________________________
>> 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
>

-- 
Rolf Welde Skeie
Solåsen 27, 5223 Nesttun, Norway
+47 92403016 / rwskeie at gmail.com


More information about the OvmsDev mailing list