[Ovmsdev] OVMS v3 - Microcontroller

Julien (JaXX) Banchet jaxx at jaxx.org
Tue Feb 2 17:43:12 HKT 2016


On 02/02/2016 10:24 AM, Mark Webb-Johnson wrote:
> Oh, and also important to bring out some expansion via sockets on side 
> of case. In particular for digital I/O.
Yeah, things need to come out :-)

I had something like this in mind:
http://www.rtd.com/IDAN/IDAN_selection.htm

Of course, at a smaller cheaper scale, Two rows of single pins leaving 
two borders free for connectors, maybe plastic frames that people will 
drill themselves for their 2$ OVMS expansion Protoshield (think : 
https://www.sparkfun.com/products/7914 ), or, simply optionnal framing 
at all, just need to keep nylon spacers
We can even imagine 1U and 2U heights :-)

Wild thought : Would it be totally crazy to have it in Arduino sizing 
and separating the CPU (+BT/Wifi if ESP32) and the Power+Can in two 
boards for easier replacement, and broader attraction to tinkering ?
CAN components end up more expensive than a handful of ESP8266 (Sorry, 
French exageration), but CAN is robust and is not likely to change 
enough before we get to OMVS v4 ... Actually, CAN itself would be a module.

JB./.

>
> Regards, Mark.
>
>> On 2 Feb 2016, at 5:21 PM, Mark Webb-Johnson <mark at webb-johnson.net 
>> <mailto:mark at webb-johnson.net>> wrote:
>>
>> My preference for connectors is those 0.1” SIP/DIP ones. They are 
>> extremely vibration resistant, breadboard compatible, stackable, etc.
>>
>> <PastedGraphic-3.tiff>
>> <PastedGraphic-2.tiff>
>>
>> When layed out properly, they also allow you to stack expansion over 
>> existing board components, without sacrificing much space.
>>
>> For bringing out lots of pins, not so good. But for enough for one or 
>> two expansion slots they work well.
>>
>> Regards, Mark.
>>
>>> On 2 Feb 2016, at 4:59 PM, Julien (JaXX) Banchet <jaxx at jaxx.org 
>>> <mailto:jaxx at jaxx.org>> wrote:
>>>
>>>
>>> On 02/02/2016 08:49 AM, Mark Webb-Johnson wrote:
>>>> Julien,
>>>>
>>>> It seems that our thinking is similar.
>>>>
>>>> I view OVMS as the CAN processor - perhaps a bridge/gateway - and 
>>>> telematics module. User Interface, Car PC, etc, systems are best 
>>>> handled externally by something that starts up and shuts down with 
>>>> the ignition switch and can suck as much power as your home PC. 
>>>> OVMS has to keep running, in as low power mode as possible, as 
>>>> telematics are required even when the car is off.
>>> Exactly, my whole point, plus, that part, externalized, with a 
>>> standardized way of communicating with the OVMS (uart/bt + 
>>> ethernet/wifi+mqtt,http://api) will give a full freedom of 
>>> implementation of the Heavyweight part. BTW: one of the extension 
>>> boards could be a power-control board with power state signaling, 
>>> MOSFETs, and a watchdog for that part
>>>>
>>>> Regarding ESP32, that is top of our shortlisted devices for 
>>>> wifi/bluetooth. But, it depends on release schedule. We want OVMS 
>>>> v3 to be FCC and CE certified, and that means we must use FCC+CE 
>>>> certified modules for the comms parts.
>>> I don't know if their distribution of 200 beta boards was a cap 
>>> limit, but maybe shooting a mail to beta at espressif.com might be 
>>> worth it, asking them for approximate timelines with it, no ?
>>>>
>>>> The overall goal is for OVMS v3 to be the microprocessor, power, 
>>>> CAN, USB, ethernet, wifi, and bluetooth, as a base module. Then, 
>>>> everything else (including cellular) are optional plugin modules. 
>>>> We could make wifi+bluetooth optional, but I suspect that they will 
>>>> not add dramatically to the cost/complexity to include as standard. 
>>>> This has got to go in an automotive environment, so plugin modules 
>>>> will most likely go on some sturdy headers on the board.
>>> BT/BLE I believe is a minimum to have: It will allow people to have 
>>> a locally connected Android App (without pumping data over a slow, 
>>> optionnal and maybe misconfigured GSM stack) and without any hassle 
>>> at that, latency can be sub 0.5s which is bareable for live 
>>> metrics... plus, not all phones implement USB OTG correctly... and 
>>> it's cablefree, which non-DIYers might appreciate.
>>>
>>> Form factor wise, my edge connector idea might not be that great, 
>>> we'd end up with a lonnnngg serie of boards, maybe stackable as an 
>>> arduino shield ? connectors are cheap, easier for the DIYer, no need 
>>> to design long pathways that get in the way for signals from border 
>>> to border...
>>>
>>>>
>>>> Regards, Mark.
>>>>
>>>>> On 2 Feb 2016, at 3:34 PM, Julien Banchet <jaxx at jaxx.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I love the OpenCV part, though I'll have to find a way to retofit 
>>>>> powersteering and brake actuators in a Twizy, that said, it all 
>>>>> shoots way beyond the scope of OVMS (even a v4/v5) imho... but, 
>>>>> but, but... an OVMS module shall be the bridge and the low-level 
>>>>> comms offloader for an optionnal "Hyper Smart OpenCV Dashboard 
>>>>> Music Streaming thingy" that a sister project can take over :-) 
>>>>> (my opinion again)
>>>>>
>>>>> So yeah, It needs to be beefy, and the ESP32 seems to be a nice 
>>>>> candidate and embeds by itself a nice load of functions (Wifi and 
>>>>> BLE!)
>>>>> http://www.pighixxx.com/test/2015/12/esp32-processor-pinout/
>>>>>
>>>>> It has no CAN, but it has SPI (can't tell how many on this pinout) 
>>>>> and plenty of HS GPIOs for native or soft UARTs. Having 2 CANbuses 
>>>>> shouldn't be an issue (I'll let those who fathomed that more than 
>>>>> me tell me wrong otherwise)
>>>>>
>>>>> I don't believe everyone needs a 2/3/4G stack, not counting that 
>>>>> those radios end up being the big bucks of the BOM.
>>>>>
>>>>> Instead, would it be possible to envision a naked board with an 
>>>>> extension bus and i2c, interrupts, multiplexed (or not) enable and 
>>>>> power lanes? (an edge fitted socket for example, each extension 
>>>>> board presents another socket)
>>>>>
>>>>> The motivation for this particular request is:
>>>>> - It lowers the base cost, with knowledge it can be enhanced, and 
>>>>> still carries Wifi+BTBLE for local connectivity with an ESP32
>>>>> - I doubt my Twizy will ever be stolen to be brought out of LoRa 
>>>>> range, and those networks are being deployed quickly, no need for 
>>>>> power hungry GSM stacks (that empty my Twizys' 12V battery in 3 
>>>>> days, driving me nuts by the way)
>>>>> - I might want a home brewed I2C GPIO extender on it, a socket 
>>>>> makes it easy to make (or a stepper motor drivers to pilot a 
>>>>> paintball gun turret fitted on the roof and shoot *ssholes)
>>>>> - The hypothetical day I upgrade to a Tesla 3, I can add that 5G 
>>>>> Module that wasn't out yet ;-)
>>>>>
>>>>> Just thoughts,
>>>>>
>>>>> JaXX
>>>>>
>>>>>
>>>>> On Mon, Feb 1, 2016 at 8:30 PM, Michael Eymann 
>>>>> <Michael.Eymann at networkz.de> wrote:
>>>>>
>>>>>     All,
>>>>>
>>>>>     what about opening our garden, providing a public park which
>>>>>     could be used for several features beside the scope of this group?
>>>>>
>>>>>     3G/4G Wlan Bluetooth GPS whatever could be added / replaced
>>>>>     easily….
>>>>>
>>>>>     what i mean is vocabulary like:
>>>>>     - raspberry pi
>>>>>     - CarPI (CarPC)
>>>>>     - OBD - smartphone speedometer gadgets (sure really useless -
>>>>>     but the mainstream love it)
>>>>>     - Harry´s laptimer support (http://www.gps-laptimer.de) //
>>>>>     video: Harry's LapTimer GPS/OBD II Video Overlay -
>>>>>     Nordschleife with 911 GTS
>>>>>     <https://www.youtube.com/watch?v=fTCNhmsFZBE>
>>>>>     https://www.youtube.com/watch?v=fTCNhmsFZBE
>>>>>     - Wlan.. repeater - hotspot… (my favorit)
>>>>>     this could also enable add on development….
>>>>>     - spotify
>>>>>     - surround view parking (raspian & openCV?) // AVM: AVM
>>>>>     (Around View Monitoring /monitor ) 4CH camera become 360
>>>>>     degree Parking Guidance System
>>>>>     <https://www.youtube.com/watch?v=1Q9iVoSvjGk>
>>>>>     https://www.youtube.com/watch?v=1Q9iVoSvjGk
>>>>>     - KITT Watch - car call?
>>>>>     - replace Infotainment systems
>>>>>     - SmartAutomation like OpenHab integration (They call it
>>>>>     „Binding“ - Tesla Model S Binding is already integrated - did
>>>>>     they overtake us? ;-) http://www.openhab.org
>>>>>     <http://www.openhab.org/>
>>>>>
>>>>>
>>>>>     views?
>>>>>
>>>>>     Michael
>>>>>
>>>>>
>>>>>     Am 01.02.2016 um 18:51 schrieb Dominik Westner <ovms at nikwest.de>:
>>>>>
>>>>>     Generally I think 3G doesn’t make a lot of sense. A new
>>>>>     platform should be 4G capable. As far as I know 2G is more
>>>>>     likely to stay longer than 3G.
>>>>>     I know already some areas in Germany and Austria where you can
>>>>>     find 4G and maybe 2G, but no 3G.
>>>>>
>>>>>     For example seeedstudio retargeted their Rephone 3G module to
>>>>>     4G after some investigations about the future of 3G.
>>>>>     (https://www.kickstarter.com/projects/seeed/rephone-kit-worlds-first-open-source-and-modular-p/posts/1468366)
>>>>>
>>>>>     Just my 2 cents
>>>>>
>>>>>     Dominik
>>>>>
>>>>>>     On 01 Feb 2016, at 18:30, Arthur Hebert <ahebert at gmail.com>
>>>>>>     wrote:
>>>>>>
>>>>>>     The Particle Electron has recently caught my attention:
>>>>>>     https://www.particle.io/cellular. Actual performance and
>>>>>>     usability are unknown, since the first units don't ship until
>>>>>>     later this month, but it has some attractive features:
>>>>>>
>>>>>>       * low-cost M2M-oriented international SMS/data plans
>>>>>>         ($3/mo. for 20k messages)
>>>>>>       * STM32F205 MCU with *1MB flash*, 128k RAM and *2 CAN buses*
>>>>>>       * free development IDE: https://www.particle.io/dev
>>>>>>       * also a free web-based dev environment at
>>>>>>         https://build.particle.io (I assume/hope this will
>>>>>>         support the Electron cellular board when it comes out)
>>>>>>
>>>>>>     I know it doesn't come close to meeting the RAM requirements,
>>>>>>     but the cellular plan is a pretty big draw IMO. Perhaps worth
>>>>>>     using this module in conjunction with another board with a
>>>>>>     better MCU?
>>>>>>
>>>>>>     -Arthur
>>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     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 <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
>>>
>>> _______________________________________________
>>> 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

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


More information about the OvmsDev mailing list