I’m trying to finalise the OVMS v3 final board layout, with the factory in China. We have some questions and seek your opinions: CAN transceivers / power Overall, the OVMS v3 system runs at 3.3V. We have two power supply sources: USB (where we use a 5V -> 3.3V regulator), and +12V vehicle power (where we use a +12V -> 3.3V switching power supply, to be as energy efficient as possible). Diodes are used for reverse-polarity protection as well as coping with the situation where both usb and vehicle power is applied simultaneously. Our problem is with the CAN transceivers. I’m used to the MCP2551 (been using it for a decade or more), but that is 5V so greatly complicates the power supply arrangements at the +12V side. We can switch to something like the SN65HVD233 transceiver that works at 3.3V. But, I am concerned about comments I am reading about 3.3V CAN transceivers and their inability to meet the ISO11898 dominant condition requirement of 3.5V. From my understanding, these 3.3V CAN transceivers get around this by driving CAN-L to 1V, to still get the differential of about 2V (recessive condition?). My concern is compatibility. What do people think about this? Any recommendations? External Connectors The idea is to retain the existing DB9 connector, with the same basic pin arrangement: DB9-M Signal 3 Chassis/Power GND 2 CAN-L (primary) 7 CAN-H (primary) 4 CAN-L (alternate CAN) 5 CAN-H (alternate CAN) 9 +12V Vehicle Power That leaves pins #1, #6, and #8 free for expansion uses. It gives us compatibility with existing OVMS cables. We would then add a second connector. The suggestions here are DB15 normal density, DB25 normal density, or DA-26 high density. My preference is the DA-26 (as DB25 is the old parallel printer style connector and very bulky). As well as power lines, expansion cards could wire to this connector to expose external inputs/outputs. What do people think about the DA-26 connector? I’m suggesting a female version (as power is carried there, and I don’t want the pins to get pushed together for a short). Note that we’ve also got a micro-usb socket, as well as space for GPS and GSM/GNS antennas. Other than that, we are good to go. Things have stabilised now with Espressif, so we can proceed with building developer boards. Regards, Mark.
Mark, I like the reliability of sticking with the 5V CAN transceiver. Why not structure the power system to use one switching power supply to go from +12V to 5V and another to go from 5V (originating from +12V or from USB) to 3.3V? The Raspberry Pi typically gets power from USB; the Model B+ needs both 3.3V and 1.8V which are provided by a tiny, high-efficiency dual buck converter chip. I tested pulling an extra 100mA from 3.3V and did not notice any significant heat from any of the power supply components. See the following for a description of the old RPi circuit that used a simple but hot regulator and a comparison to the new circuit: https://learn.adafruit.com/introducing-the-raspberry-pi-model-b-plus-plus-di... That article also mentions (but does not fully explain) the use of a MOSFET instead of a diode for power supply routing. Regarging external connectors, I did not know a second connector was planned. However, using a higher-density connector makes sense these days. I've handled many DB-25 connectors for RS-232 serial in years past, but those seem positively gigantic now. BTW, I think it is a DE9-M, not DB9-M. -- Steve On Thu, 30 Mar 2017, Mark Webb-Johnson wrote:
I’m trying to finalise the OVMS v3 final board layout, with the factory in China. We have some questions and seek your opinions:
CAN transceivers / power
Overall, the OVMS v3 system runs at 3.3V. We have two power supply sources: USB (where we use a 5V -> 3.3V regulator), and +12V vehicle power (where we use a +12V -> 3.3V switching power supply, to be as energy efficient as possible). Diodes are used for reverse-polarity protection as well as coping with the situation where both usb and vehicle power is applied simultaneously.
Our problem is with the CAN transceivers. I’m used to the MCP2551 (been using it for a decade or more), but that is 5V so greatly complicates the power supply arrangements at the +12V side. We can switch to something like the SN65HVD233 transceiver that works at 3.3V.
But, I am concerned about comments I am reading about 3.3V CAN transceivers and their inability to meet the ISO11898 dominant condition requirement of 3.5V. From my understanding, these 3.3V CAN transceivers get around this by driving CAN-L to 1V, to still get the differential of about 2V (recessive condition?). My concern is compatibility.
What do people think about this? Any recommendations?
External Connectors
The idea is to retain the existing DB9 connector, with the same basic pin arrangement:
DB9-M Signal 3 Chassis/Power GND 2 CAN-L (primary) 7 CAN-H (primary) 4 CAN-L (alternate CAN) 5 CAN-H (alternate CAN) 9 +12V Vehicle Power
That leaves pins #1, #6, and #8 free for expansion uses. It gives us compatibility with existing OVMS cables.
We would then add a second connector. The suggestions here are DB15 normal density, DB25 normal density, or DA-26 high density. My preference is the DA-26 (as DB25 is the old parallel printer style connector and very bulky). As well as power lines, expansion cards could wire to this connector to expose external inputs/outputs.
What do people think about the DA-26 connector? I’m suggesting a female version (as power is carried there, and I don’t want the pins to get pushed together for a short).
Note that we’ve also got a micro-usb socket, as well as space for GPS and GSM/GNS antennas.
Other than that, we are good to go. Things have stabilised now with Espressif, so we can proceed with building developer boards.
Regards, Mark.
Stephen, Thanks for your quick reply. My concern is that historically we’ve had a lot of power wastage in OVMS v2 (and v1 before that). We used LM style power regulators, and those burned off the 12V->5V difference as heat. Kind of like to Raspberry Pi A and B (but in our case 12V->5V is being burned off, not 5V->3.3V). Cheap, clean and simple, but very ‘lossy’. Moving to a 12V->5V pre-conversion, then 5V->3.3V from both USB and 12V sides, seems a simple way to go, but what sort of impact on efficiency does that sacrifice? The other concern is noise. For the GSM modem (and presumably ESP32, although I haven’t seen so much concern raised there), we need to keep things very clean. Cost wise, the 3.3V transceivers are about 3+ times the price of the venerable MCP2551. Regarding the extra connector, the idea is to provide a base module with base functionality. Then have a plug-in architecture (using SIP strips) that will allow an expansion board to be added. That expansion board should be able to connect to the microprocessor, do whatever it needs to do, then expose itself on the extra connector pins. The idea is to have two of these - one for the optional modem, and one for general expansion. Regards, Mark. P.S. In the above I say 12V, but it is more like 14V - 15V in modern cars.
On 30 Mar 2017, at 1:33 PM, Stephen Casner <casner@acm.org> wrote:
Mark,
I like the reliability of sticking with the 5V CAN transceiver. Why not structure the power system to use one switching power supply to go from +12V to 5V and another to go from 5V (originating from +12V or from USB) to 3.3V? The Raspberry Pi typically gets power from USB; the Model B+ needs both 3.3V and 1.8V which are provided by a tiny, high-efficiency dual buck converter chip. I tested pulling an extra 100mA from 3.3V and did not notice any significant heat from any of the power supply components.
See the following for a description of the old RPi circuit that used a simple but hot regulator and a comparison to the new circuit:
https://learn.adafruit.com/introducing-the-raspberry-pi-model-b-plus-plus-di...
That article also mentions (but does not fully explain) the use of a MOSFET instead of a diode for power supply routing.
Regarging external connectors, I did not know a second connector was planned. However, using a higher-density connector makes sense these days. I've handled many DB-25 connectors for RS-232 serial in years past, but those seem positively gigantic now.
BTW, I think it is a DE9-M, not DB9-M.
-- Steve
On Thu, 30 Mar 2017, Mark Webb-Johnson wrote:
I’m trying to finalise the OVMS v3 final board layout, with the factory in China. We have some questions and seek your opinions:
CAN transceivers / power
Overall, the OVMS v3 system runs at 3.3V. We have two power supply sources: USB (where we use a 5V -> 3.3V regulator), and +12V vehicle power (where we use a +12V -> 3.3V switching power supply, to be as energy efficient as possible). Diodes are used for reverse-polarity protection as well as coping with the situation where both usb and vehicle power is applied simultaneously.
Our problem is with the CAN transceivers. I’m used to the MCP2551 (been using it for a decade or more), but that is 5V so greatly complicates the power supply arrangements at the +12V side. We can switch to something like the SN65HVD233 transceiver that works at 3.3V.
But, I am concerned about comments I am reading about 3.3V CAN transceivers and their inability to meet the ISO11898 dominant condition requirement of 3.5V. From my understanding, these 3.3V CAN transceivers get around this by driving CAN-L to 1V, to still get the differential of about 2V (recessive condition?). My concern is compatibility.
What do people think about this? Any recommendations?
External Connectors
The idea is to retain the existing DB9 connector, with the same basic pin arrangement:
DB9-M Signal 3 Chassis/Power GND 2 CAN-L (primary) 7 CAN-H (primary) 4 CAN-L (alternate CAN) 5 CAN-H (alternate CAN) 9 +12V Vehicle Power
That leaves pins #1, #6, and #8 free for expansion uses. It gives us compatibility with existing OVMS cables.
We would then add a second connector. The suggestions here are DB15 normal density, DB25 normal density, or DA-26 high density. My preference is the DA-26 (as DB25 is the old parallel printer style connector and very bulky). As well as power lines, expansion cards could wire to this connector to expose external inputs/outputs.
What do people think about the DA-26 connector? I’m suggesting a female version (as power is carried there, and I don’t want the pins to get pushed together for a short).
Note that we’ve also got a micro-usb socket, as well as space for GPS and GSM/GNS antennas.
Other than that, we are good to go. Things have stabilised now with Espressif, so we can proceed with building developer boards.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Mark, I think the buck converters tend to be 80-90% efficient, so I don't think efficiency of my proposal would be a problem. I don't know whether noise is a problem or whether it could be filtered. Since you plan to use some configuration of switching power supplies in any case there will be some noise. Another possibility would be something like the Renesas RAA230232GSB dual converter that takes 4.5 to 16V in and has two outputs, 5V and 3.3V. I found this one poking around at DigiKey. Only problem was that the item listing was for a 2500-part tape. -- Steve On Thu, 30 Mar 2017, Mark Webb-Johnson wrote:
Stephen,
Thanks for your quick reply.
My concern is that historically we've had a lot of power wastage in OVMS v2 (and v1 before that). We used LM style power regulators, and those burned off the 12V->5V difference as heat. Kind of like to Raspberry Pi A and B (but in our case 12V->5V is being burned off, not 5V->3.3V). Cheap, clean and simple, but very 'lossy'.
Moving to a 12V->5V pre-conversion, then 5V->3.3V from both USB and 12V sides, seems a simple way to go, but what sort of impact on efficiency does that sacrifice?
The other concern is noise. For the GSM modem (and presumably ESP32, although I haven't seen so much concern raised there), we need to keep things very clean.
Cost wise, the 3.3V transceivers are about 3+ times the price of the venerable MCP2551.
Regarding the extra connector, the idea is to provide a base module with base functionality. Then have a plug-in architecture (using SIP strips) that will allow an expansion board to be added. That expansion board should be able to connect to the microprocessor, do whatever it needs to do, then expose itself on the extra connector pins. The idea is to have two of these - one for the optional modem, and one for general expansion.
Regards, Mark.
P.S. In the above I say 12V, but it is more like 14V - 15V in modern cars.
On 30 Mar 2017, at 1:33 PM, Stephen Casner <casner@acm.org> wrote:
Mark,
I like the reliability of sticking with the 5V CAN transceiver. Why not structure the power system to use one switching power supply to go from +12V to 5V and another to go from 5V (originating from +12V or from USB) to 3.3V? The Raspberry Pi typically gets power from USB; the Model B+ needs both 3.3V and 1.8V which are provided by a tiny, high-efficiency dual buck converter chip. I tested pulling an extra 100mA from 3.3V and did not notice any significant heat from any of the power supply components.
See the following for a description of the old RPi circuit that used a simple but hot regulator and a comparison to the new circuit:
https://learn.adafruit.com/introducing-the-raspberry-pi-model-b-plus-plus-di...
That article also mentions (but does not fully explain) the use of a MOSFET instead of a diode for power supply routing.
Regarging external connectors, I did not know a second connector was planned. However, using a higher-density connector makes sense these days. I've handled many DB-25 connectors for RS-232 serial in years past, but those seem positively gigantic now.
BTW, I think it is a DE9-M, not DB9-M.
-- Steve
On Thu, 30 Mar 2017, Mark Webb-Johnson wrote:
I'm trying to finalise the OVMS v3 final board layout, with the factory in China. We have some questions and seek your opinions:
CAN transceivers / power
Overall, the OVMS v3 system runs at 3.3V. We have two power supply sources: USB (where we use a 5V -> 3.3V regulator), and +12V vehicle power (where we use a +12V -> 3.3V switching power supply, to be as energy efficient as possible). Diodes are used for reverse-polarity protection as well as coping with the situation where both usb and vehicle power is applied simultaneously.
Our problem is with the CAN transceivers. I'm used to the MCP2551 (been using it for a decade or more), but that is 5V so greatly complicates the power supply arrangements at the +12V side. We can switch to something like the SN65HVD233 transceiver that works at 3.3V.
But, I am concerned about comments I am reading about 3.3V CAN transceivers and their inability to meet the ISO11898 dominant condition requirement of 3.5V. From my understanding, these 3.3V CAN transceivers get around this by driving CAN-L to 1V, to still get the differential of about 2V (recessive condition?). My concern is compatibility.
What do people think about this? Any recommendations?
External Connectors
The idea is to retain the existing DB9 connector, with the same basic pin arrangement:
DB9-M Signal 3 Chassis/Power GND 2 CAN-L (primary) 7 CAN-H (primary) 4 CAN-L (alternate CAN) 5 CAN-H (alternate CAN) 9 +12V Vehicle Power
That leaves pins #1, #6, and #8 free for expansion uses. It gives us compatibility with existing OVMS cables.
We would then add a second connector. The suggestions here are DB15 normal density, DB25 normal density, or DA-26 high density. My preference is the DA-26 (as DB25 is the old parallel printer style connector and very bulky). As well as power lines, expansion cards could wire to this connector to expose external inputs/outputs.
What do people think about the DA-26 connector? I'm suggesting a female version (as power is carried there, and I don't want the pins to get pushed together for a short).
Note that we've also got a micro-usb socket, as well as space for GPS and GSM/GNS antennas.
Other than that, we are good to go. Things have stabilised now with Espressif, so we can proceed with building developer boards.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Looks interesting. But what would happen if the input voltage was 5V (USB)? Would it still be able to output both 5V and 3.3V? From my recollection, Vin always has to be above Vout by some amount (depending on current), due to internal resistance in the buck converter as well as maximum duty cycle. That said, I think a bypass may resolve that where in USB mode we just take the 5V direct from USB. Regards, Mark.
On 30 Mar 2017, at 3:39 PM, Stephen Casner <casner@acm.org> wrote:
Mark,
I think the buck converters tend to be 80-90% efficient, so I don't think efficiency of my proposal would be a problem. I don't know whether noise is a problem or whether it could be filtered. Since you plan to use some configuration of switching power supplies in any case there will be some noise.
Another possibility would be something like the Renesas RAA230232GSB dual converter that takes 4.5 to 16V in and has two outputs, 5V and 3.3V. I found this one poking around at DigiKey. Only problem was that the item listing was for a 2500-part tape.
-- Steve
On Thu, 30 Mar 2017, Mark Webb-Johnson wrote:
Stephen,
Thanks for your quick reply.
My concern is that historically we've had a lot of power wastage in OVMS v2 (and v1 before that). We used LM style power regulators, and those burned off the 12V->5V difference as heat. Kind of like to Raspberry Pi A and B (but in our case 12V->5V is being burned off, not 5V->3.3V). Cheap, clean and simple, but very 'lossy'.
Moving to a 12V->5V pre-conversion, then 5V->3.3V from both USB and 12V sides, seems a simple way to go, but what sort of impact on efficiency does that sacrifice?
The other concern is noise. For the GSM modem (and presumably ESP32, although I haven't seen so much concern raised there), we need to keep things very clean.
Cost wise, the 3.3V transceivers are about 3+ times the price of the venerable MCP2551.
Regarding the extra connector, the idea is to provide a base module with base functionality. Then have a plug-in architecture (using SIP strips) that will allow an expansion board to be added. That expansion board should be able to connect to the microprocessor, do whatever it needs to do, then expose itself on the extra connector pins. The idea is to have two of these - one for the optional modem, and one for general expansion.
Regards, Mark.
P.S. In the above I say 12V, but it is more like 14V - 15V in modern cars.
On 30 Mar 2017, at 1:33 PM, Stephen Casner <casner@acm.org> wrote:
Mark,
I like the reliability of sticking with the 5V CAN transceiver. Why not structure the power system to use one switching power supply to go from +12V to 5V and another to go from 5V (originating from +12V or from USB) to 3.3V? The Raspberry Pi typically gets power from USB; the Model B+ needs both 3.3V and 1.8V which are provided by a tiny, high-efficiency dual buck converter chip. I tested pulling an extra 100mA from 3.3V and did not notice any significant heat from any of the power supply components.
See the following for a description of the old RPi circuit that used a simple but hot regulator and a comparison to the new circuit:
https://learn.adafruit.com/introducing-the-raspberry-pi-model-b-plus-plus-di...
That article also mentions (but does not fully explain) the use of a MOSFET instead of a diode for power supply routing.
Regarging external connectors, I did not know a second connector was planned. However, using a higher-density connector makes sense these days. I've handled many DB-25 connectors for RS-232 serial in years past, but those seem positively gigantic now.
BTW, I think it is a DE9-M, not DB9-M.
-- Steve
On Thu, 30 Mar 2017, Mark Webb-Johnson wrote:
I'm trying to finalise the OVMS v3 final board layout, with the factory in China. We have some questions and seek your opinions:
CAN transceivers / power
Overall, the OVMS v3 system runs at 3.3V. We have two power supply sources: USB (where we use a 5V -> 3.3V regulator), and +12V vehicle power (where we use a +12V -> 3.3V switching power supply, to be as energy efficient as possible). Diodes are used for reverse-polarity protection as well as coping with the situation where both usb and vehicle power is applied simultaneously.
Our problem is with the CAN transceivers. I'm used to the MCP2551 (been using it for a decade or more), but that is 5V so greatly complicates the power supply arrangements at the +12V side. We can switch to something like the SN65HVD233 transceiver that works at 3.3V.
But, I am concerned about comments I am reading about 3.3V CAN transceivers and their inability to meet the ISO11898 dominant condition requirement of 3.5V. From my understanding, these 3.3V CAN transceivers get around this by driving CAN-L to 1V, to still get the differential of about 2V (recessive condition?). My concern is compatibility.
What do people think about this? Any recommendations?
External Connectors
The idea is to retain the existing DB9 connector, with the same basic pin arrangement:
DB9-M Signal 3 Chassis/Power GND 2 CAN-L (primary) 7 CAN-H (primary) 4 CAN-L (alternate CAN) 5 CAN-H (alternate CAN) 9 +12V Vehicle Power
That leaves pins #1, #6, and #8 free for expansion uses. It gives us compatibility with existing OVMS cables.
We would then add a second connector. The suggestions here are DB15 normal density, DB25 normal density, or DA-26 high density. My preference is the DA-26 (as DB25 is the old parallel printer style connector and very bulky). As well as power lines, expansion cards could wire to this connector to expose external inputs/outputs.
What do people think about the DA-26 connector? I'm suggesting a female version (as power is carried there, and I don't want the pins to get pushed together for a short).
Note that we've also got a micro-usb socket, as well as space for GPS and GSM/GNS antennas.
Other than that, we are good to go. Things have stabilised now with Espressif, so we can proceed with building developer boards.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I've used the MAXIM MAX1595 to produce 5V in many products. I don't know if that would help your situation, but I agree that sticking with the "MCP2551" is probably the best choice. However, I just noticed that Microchip mark the MCP2551 as Not Recommended For New Designs. They're recommending the MCP2561 instead. The good news is that it is also a 5V part, so there should be none of the 3.3V versus 3.5V issues. A buck converter from 15V to 5V could be quite efficient, but I don't know what you would do if it turns out to be noisy. I suppose that a passive RC filter bank could smooth things out if your buck converter is willing to produce the extra voltage that will be bled off in the passive filter. That's not as efficient as possible, but it might be as clean as an LM regulator and still more efficient than an LM. By the way, if a chip needs 5V, then it usually requires at least 4.75V as a bare minimum. The MCP2551 requires at least 4.5V minimum. One thing to be aware of is that USB only guarantees 4.01V on the VBUS if you're on the far side of a passive hub, so I've never considered it safe to run a 5V chip directly off of the USB VBUS. Sure, it will probably work 99% of the time, but I don't like ignoring part of a specification. I mention all of this because I use the MAX1595 in USB Devices that include 5V chips, because I don't want to get caught with less than 4.75V in some situations. In that case, it might be easier to produce the 5V from the 3.3V supply, and then use the diode "or" circuit to feed the 3.3V regulator. The MAX1595 works by using a capacitive voltage doubler, then it bleeds that off. I've actually run the MAX1595 off the 3.3V instead of the VBUS just to avoid bleeding off the excess. 3.3V in becomes 6.6V internally, whereas the nominal 5V VBUS becomes 10V internally. I now use the MAX1595ETC50 in QFN12 packaging because it can handle the additional heat. The data sheet gives equations to calculate the wattage given your circuit needs. Brian Willoughby Sound Consulting On Mar 29, 2017, at 11:18 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
My concern is that historically we’ve had a lot of power wastage in OVMS v2 (and v1 before that). We used LM style power regulators, and those burned off the 12V->5V difference as heat. Kind of like to Raspberry Pi A and B (but in our case 12V->5V is being burned off, not 5V->3.3V). Cheap, clean and simple, but very ‘lossy’.
Moving to a 12V->5V pre-conversion, then 5V->3.3V from both USB and 12V sides, seems a simple way to go, but what sort of impact on efficiency does that sacrifice?
The other concern is noise. For the GSM modem (and presumably ESP32, although I haven’t seen so much concern raised there), we need to keep things very clean.
Cost wise, the 3.3V transceivers are about 3+ times the price of the venerable MCP2551.
Regarding the extra connector, the idea is to provide a base module with base functionality. Then have a plug-in architecture (using SIP strips) that will allow an expansion board to be added. That expansion board should be able to connect to the microprocessor, do whatever it needs to do, then expose itself on the extra connector pins. The idea is to have two of these - one for the optional modem, and one for general expansion.
Regards, Mark.
P.S. In the above I say 12V, but it is more like 14V - 15V in modern cars.
On Thu, 30 Mar 2017, Mark Webb-Johnson wrote:
I’m trying to finalise the OVMS v3 final board layout, with the factory in China. We have some questions and seek your opinions:
CAN transceivers / power
Overall, the OVMS v3 system runs at 3.3V. We have two power supply sources: USB (where we use a 5V -> 3.3V regulator), and +12V vehicle power (where we use a +12V -> 3.3V switching power supply, to be as energy efficient as possible). Diodes are used for reverse-polarity protection as well as coping with the situation where both usb and vehicle power is applied simultaneously.
Our problem is with the CAN transceivers. I’m used to the MCP2551 (been using it for a decade or more), but that is 5V so greatly complicates the power supply arrangements at the +12V side. We can switch to something like the SN65HVD233 transceiver that works at 3.3V.
But, I am concerned about comments I am reading about 3.3V CAN transceivers and their inability to meet the ISO11898 dominant condition requirement of 3.5V. From my understanding, these 3.3V CAN transceivers get around this by driving CAN-L to 1V, to still get the differential of about 2V (recessive condition?). My concern is compatibility.
What do people think about this? Any recommendations?
External Connectors
The idea is to retain the existing DB9 connector, with the same basic pin arrangement:
DB9-M Signal 3 Chassis/Power GND 2 CAN-L (primary) 7 CAN-H (primary) 4 CAN-L (alternate CAN) 5 CAN-H (alternate CAN) 9 +12V Vehicle Power
That leaves pins #1, #6, and #8 free for expansion uses. It gives us compatibility with existing OVMS cables.
We would then add a second connector. The suggestions here are DB15 normal density, DB25 normal density, or DA-26 high density. My preference is the DA-26 (as DB25 is the old parallel printer style connector and very bulky). As well as power lines, expansion cards could wire to this connector to expose external inputs/outputs.
What do people think about the DA-26 connector? I’m suggesting a female version (as power is carried there, and I don’t want the pins to get pushed together for a short).
Note that we’ve also got a micro-usb socket, as well as space for GPS and GSM/GNS antennas.
Other than that, we are good to go. Things have stabilised now with Espressif, so we can proceed with building developer boards.
Regards, Mark.
I'm unsure of why the 3.3v transceiver would be a problem. CAN wiring is supposed to be differential and it isn't supposed to matter if it is 20V and 18V relative to local ground or 4V and 2V. There is isn't a requirement to keep a shared ground between two CAN devices so how would a remote node even know what the "voltage" of CAN-L is? Voltage is only defined between two points so if you don't share a ground between two nodes then the only voltage the transceiver knows is CAN-L to CAN-H which will range by the proper amount whether you use a 5V or 3.3V transceiver. I've used the SN65HVD series transceivers in all sorts of things and never had a single problem. I've also used the ISO1050 isolated transceiver and also had no problems with different devices. But, if the 5V transceiver is cheaper and you can get 5V easily enough then maybe that's still the way to go. I'm just saying in my experience the concern isn't terribly warranted. YMMV. On Wed, Mar 29, 2017 at 9:07 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I’m trying to finalise the OVMS v3 final board layout, with the factory in China. We have some questions and seek your opinions:
CAN transceivers / power
Overall, the OVMS v3 system runs at 3.3V. We have two power supply sources: USB (where we use a 5V -> 3.3V regulator), and +12V vehicle power (where we use a +12V -> 3.3V switching power supply, to be as energy efficient as possible). Diodes are used for reverse-polarity protection as well as coping with the situation where both usb and vehicle power is applied simultaneously.
Our problem is with the CAN transceivers. I’m used to the MCP2551 (been using it for a decade or more), but that is 5V so greatly complicates the power supply arrangements at the +12V side. We can switch to something like the SN65HVD233 transceiver that works at 3.3V.
But, I am concerned about comments I am reading about 3.3V CAN transceivers and their inability to meet the ISO11898 dominant condition requirement of 3.5V. From my understanding, these 3.3V CAN transceivers get around this by driving CAN-L to 1V, to still get the differential of about 2V (recessive condition?). My concern is compatibility.
What do people think about this? Any recommendations?
External Connectors
The idea is to retain the existing DB9 connector, with the same basic pin arrangement:
DB9-M Signal 3 Chassis/Power GND 2 CAN-L (primary) 7 CAN-H (primary) 4 CAN-L (alternate CAN) 5 CAN-H (alternate CAN) 9 +12V Vehicle Power
That leaves pins #1, #6, and #8 free for expansion uses. It gives us compatibility with existing OVMS cables.
We would then add a second connector. The suggestions here are DB15 normal density, DB25 normal density, or DA-26 high density. My preference is the DA-26 (as DB25 is the old parallel printer style connector and very bulky). As well as power lines, expansion cards could wire to this connector to expose external inputs/outputs.
What do people think about the DA-26 connector? I’m suggesting a female version (as power is carried there, and I don’t want the pins to get pushed together for a short).
Note that we’ve also got a micro-usb socket, as well as space for GPS and GSM/GNS antennas.
Other than that, we are good to go. Things have stabilised now with Espressif, so we can proceed with building developer boards.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 31/03/2017, at 3:33 AM, Collin Kidder wrote:
I'm unsure of why the 3.3v transceiver would be a problem. CAN wiring is supposed to be differential
Totally agree. TI has an app note somewhere that argues that their 3.3V chips achieve the spec’d differential mode voltage, by slewing the offset from ground slightly (still well within specs) But you don’t want to blow out cost. Some of the TI chips will handle much more voltage, some cases +/-75V, which will make the device immune to almost anything in a car (keep away from the spark plugs or HV battery though!) Another thing to consider in the power supply is Alternator “load dump”. Only applicable to cars with alternators, but what happens is when a large 12V load turns off, say airconditioner or powerful spotlights, the alternator field decays relatively slowly, blasting the same output current into the 12V supply. If the battery can’t accept the current, voltages as high as 80V, with whatever current the load was drawing can appear for a millisecond or so on the 12V. If your device happens to be the most susceptible device in the car, its the one that is going to wear it. Something like a high surge rating zener or TVS and maybe a polyfuse might be enough to protect against it. Edward
I think this is the references application note. It makes a strong argument: http://www.ti.com/lit/an/slla337/slla337.pdf <http://www.ti.com/lit/an/slla337/slla337.pdf> Regards, Mark.
On 31 Mar 2017, at 4:07 AM, Edward Cheeseman <cheesemanedward@gmail.com> wrote:
On 31/03/2017, at 3:33 AM, Collin Kidder wrote:
I'm unsure of why the 3.3v transceiver would be a problem. CAN wiring is supposed to be differential
Totally agree. TI has an app note somewhere that argues that their 3.3V chips achieve the spec’d differential mode voltage, by slewing the offset from ground slightly (still well within specs) But you don’t want to blow out cost. Some of the TI chips will handle much more voltage, some cases +/-75V, which will make the device immune to almost anything in a car (keep away from the spark plugs or HV battery though!)
Another thing to consider in the power supply is Alternator “load dump”. Only applicable to cars with alternators, but what happens is when a large 12V load turns off, say airconditioner or powerful spotlights, the alternator field decays relatively slowly, blasting the same output current into the 12V supply. If the battery can’t accept the current, voltages as high as 80V, with whatever current the load was drawing can appear for a millisecond or so on the 12V. If your device happens to be the most susceptible device in the car, its the one that is going to wear it.
Something like a high surge rating zener or TVS and maybe a polyfuse might be enough to protect against it.
Edward _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
It seems that a dual voltage design would not be ideal. We’d have to go 12V -> 5V, and then 5V -> 3.3V. But then USB 5V is not necessarily 5V, so we would also have to deal with boosting that if necessary. We could use a dual-output buck converter 12V -> 5V and 3.3V. But, then we still have to deal with the USB issue for true 5V. Reading what all you guys are saying (thanks to all that gave feedback), it does seem that the concerns are unwarranted. Perhaps we can build the dev boards just pure 3.3V, and see how it goes. We’d use a high range buck converter to bring everything down to 3.3V. If we can find one that would also work in the USB 5V range, then we could just use that. If not, we use a cheap and simple 5V->3.3V device. I’ll ask the China guys what they can recommend based on what they have available and popular in their market. Regards, Mark.
On 30 Mar 2017, at 10:33 PM, Collin Kidder <collink@kkmfg.com> wrote:
I'm unsure of why the 3.3v transceiver would be a problem. CAN wiring is supposed to be differential and it isn't supposed to matter if it is 20V and 18V relative to local ground or 4V and 2V. There is isn't a requirement to keep a shared ground between two CAN devices so how would a remote node even know what the "voltage" of CAN-L is? Voltage is only defined between two points so if you don't share a ground between two nodes then the only voltage the transceiver knows is CAN-L to CAN-H which will range by the proper amount whether you use a 5V or 3.3V transceiver. I've used the SN65HVD series transceivers in all sorts of things and never had a single problem. I've also used the ISO1050 isolated transceiver and also had no problems with different devices. But, if the 5V transceiver is cheaper and you can get 5V easily enough then maybe that's still the way to go. I'm just saying in my experience the concern isn't terribly warranted. YMMV.
On Wed, Mar 29, 2017 at 9:07 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I’m trying to finalise the OVMS v3 final board layout, with the factory in China. We have some questions and seek your opinions:
CAN transceivers / power
Overall, the OVMS v3 system runs at 3.3V. We have two power supply sources: USB (where we use a 5V -> 3.3V regulator), and +12V vehicle power (where we use a +12V -> 3.3V switching power supply, to be as energy efficient as possible). Diodes are used for reverse-polarity protection as well as coping with the situation where both usb and vehicle power is applied simultaneously.
Our problem is with the CAN transceivers. I’m used to the MCP2551 (been using it for a decade or more), but that is 5V so greatly complicates the power supply arrangements at the +12V side. We can switch to something like the SN65HVD233 transceiver that works at 3.3V.
But, I am concerned about comments I am reading about 3.3V CAN transceivers and their inability to meet the ISO11898 dominant condition requirement of 3.5V. From my understanding, these 3.3V CAN transceivers get around this by driving CAN-L to 1V, to still get the differential of about 2V (recessive condition?). My concern is compatibility.
What do people think about this? Any recommendations?
External Connectors
The idea is to retain the existing DB9 connector, with the same basic pin arrangement:
DB9-M Signal 3 Chassis/Power GND 2 CAN-L (primary) 7 CAN-H (primary) 4 CAN-L (alternate CAN) 5 CAN-H (alternate CAN) 9 +12V Vehicle Power
That leaves pins #1, #6, and #8 free for expansion uses. It gives us compatibility with existing OVMS cables.
We would then add a second connector. The suggestions here are DB15 normal density, DB25 normal density, or DA-26 high density. My preference is the DA-26 (as DB25 is the old parallel printer style connector and very bulky). As well as power lines, expansion cards could wire to this connector to expose external inputs/outputs.
What do people think about the DA-26 connector? I’m suggesting a female version (as power is carried there, and I don’t want the pins to get pushed together for a short).
Note that we’ve also got a micro-usb socket, as well as space for GPS and GSM/GNS antennas.
Other than that, we are good to go. Things have stabilised now with Espressif, so we can proceed with building developer boards.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
My recommendation for a step down converter: The AOZ1280CI is cheap, has a wide voltage input range (3-26V), and can deliver up to 1.2A at 0.8-23V Another good thing: it switches at 1.5Mhz, so the inductor can be kept small. -Michael Op 31-3-2017 om 7:30 schreef Mark Webb-Johnson:
It seems that a dual voltage design would not be ideal.
1. We’d have to go 12V -> 5V, and then 5V -> 3.3V.
2. But then USB 5V is not necessarily 5V, so we would also have to deal with boosting that if necessary.
3. We could use a dual-output buck converter 12V -> 5V and 3.3V. But, then we still have to deal with the USB issue for true 5V.
Reading what all you guys are saying (thanks to all that gave feedback), it does seem that the concerns are unwarranted.
Perhaps we can build the dev boards just pure 3.3V, and see how it goes. We’d use a high range buck converter to bring everything down to 3.3V. If we can find one that would also work in the USB 5V range, then we could just use that. If not, we use a cheap and simple 5V->3.3V device. I’ll ask the China guys what they can recommend based on what they have available and popular in their market.
Regards, Mark.
On 30 Mar 2017, at 10:33 PM, Collin Kidder <collink@kkmfg.com <mailto:collink@kkmfg.com>> wrote:
I'm unsure of why the 3.3v transceiver would be a problem. CAN wiring is supposed to be differential and it isn't supposed to matter if it is 20V and 18V relative to local ground or 4V and 2V. There is isn't a requirement to keep a shared ground between two CAN devices so how would a remote node even know what the "voltage" of CAN-L is? Voltage is only defined between two points so if you don't share a ground between two nodes then the only voltage the transceiver knows is CAN-L to CAN-H which will range by the proper amount whether you use a 5V or 3.3V transceiver. I've used the SN65HVD series transceivers in all sorts of things and never had a single problem. I've also used the ISO1050 isolated transceiver and also had no problems with different devices. But, if the 5V transceiver is cheaper and you can get 5V easily enough then maybe that's still the way to go. I'm just saying in my experience the concern isn't terribly warranted. YMMV.
On Wed, Mar 29, 2017 at 9:07 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
I’m trying to finalise the OVMS v3 final board layout, with the factory in China. We have some questions and seek your opinions:
CAN transceivers / power
Overall, the OVMS v3 system runs at 3.3V. We have two power supply sources: USB (where we use a 5V -> 3.3V regulator), and +12V vehicle power (where we use a +12V -> 3.3V switching power supply, to be as energy efficient as possible). Diodes are used for reverse-polarity protection as well as coping with the situation where both usb and vehicle power is applied simultaneously.
Our problem is with the CAN transceivers. I’m used to the MCP2551 (been using it for a decade or more), but that is 5V so greatly complicates the power supply arrangements at the +12V side. We can switch to something like the SN65HVD233 transceiver that works at 3.3V.
But, I am concerned about comments I am reading about 3.3V CAN transceivers and their inability to meet the ISO11898 dominant condition requirement of 3.5V. From my understanding, these 3.3V CAN transceivers get around this by driving CAN-L to 1V, to still get the differential of about 2V (recessive condition?). My concern is compatibility.
What do people think about this? Any recommendations?
External Connectors
The idea is to retain the existing DB9 connector, with the same basic pin arrangement:
DB9-M Signal 3 Chassis/Power GND 2 CAN-L (primary) 7 CAN-H (primary) 4 CAN-L (alternate CAN) 5 CAN-H (alternate CAN) 9 +12V Vehicle Power
That leaves pins #1, #6, and #8 free for expansion uses. It gives us compatibility with existing OVMS cables.
We would then add a second connector. The suggestions here are DB15 normal density, DB25 normal density, or DA-26 high density. My preference is the DA-26 (as DB25 is the old parallel printer style connector and very bulky). As well as power lines, expansion cards could wire to this connector to expose external inputs/outputs.
What do people think about the DA-26 connector? I’m suggesting a female version (as power is carried there, and I don’t want the pins to get pushed together for a short).
Note that we’ve also got a micro-usb socket, as well as space for GPS and GSM/GNS antennas.
Other than that, we are good to go. Things have stabilised now with Espressif, so we can proceed with building developer boards.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Attached is the almost final schematic for OVMS v3. Only one minor typo where the SPI CS line for the MAX7317 should be SP_CS3 (incorrectly marked as SP_CS2 on the attached schematic). Other that that, it seems fine. Rather than the OVMS v2 fixed fuse, we’ve now got a resettable 0.75A/1.5A fuse on the incoming 12V. We’re trying to use the (recommended here) AOZ1280CI buck converter for both 12V and 5V down to 3.3V. The entire board past that point is 3.3V. We’ve got a BTS452R for switched 12V output, a 128Mbit external flash, CP2102 for USB-async, MAX7317 for I/O expansion, SD card, 3 CAN bus (one on board, two using MCP2515, and all three using SN65HVD233D 3.3V transceivers). Also attached is the PCB layout overview. Board at the moment is a hair under 10cm x 10cm (larger than OVMS v2) - we’re constrained by all those external connectors and two large internal expansion sockets. Any comments/suggestions, as always, appreciated. We’re going to PCB fabrication later this week, and with luck I’ll have a couple of boards in my hands late next week (or early the week after). Then I’ll finalise the Quality Control firmware (a firmware option to simply test and exercise all the components on the board). If the boards are ok, we’ll then get the size and layout finalised and produce a small hand-soldered run for developers (late this month). The side project of looking at 3G/4G modems has also started. This is going to be on one of those optional expansion slots to allow us to use different modems for different functions. I’m used to SIMCOM, but it seems their selection is getting complicated (particularly for 4G). I see the SIM5320A has 3G and GPS, which seems good but is quite dated now. SIM5320A:Dual-Band UMTS/HSDPA 850/1900MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320(J)E:Dual-Band UMTS/HSDPA 900/2100MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320J:Dual-Band UMTS/HSDPA 850(800)/2100MHz Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz It does have the CMUX, which is very nice (gives us four virtual ports over the single async port, so easier to deal with AT command control). If anyone has any suggestions for the modem, it would be helpful. Something with GPS would be ideal. Regards, Mark.
Isn't LTE-M the way to go? Something like the sequans monarch? http://www.sequans.com/products-solutions/streamlitelte/monarch-lte-platform...
On 8. May 2017, at 07:41, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
The side project of looking at 3G/4G modems has also started. This is going to be on one of those optional expansion slots to allow us to use different modems for different functions. I’m used to SIMCOM, but it seems their selection is getting complicated (particularly for 4G). I see the SIM5320A has 3G and GPS, which seems good but is quite dated now. SIM5320A:Dual-Band UMTS/HSDPA 850/1900MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320(J)E:Dual-Band UMTS/HSDPA 900/2100MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320J:Dual-Band UMTS/HSDPA 850(800)/2100MHz Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz It does have the CMUX, which is very nice (gives us four virtual ports over the single async port, so easier to deal with AT command control).
If anyone has any suggestions for the modem, it would be helpful. Something with GPS would be ideal.
Regards, Mark.
<OVMS_V3_Schematic_CN_20170503.pdf> <OVMS_V3_Layout_CN_20170508.pdf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
LTE-M Is that ‘prime time’ already? I thought that wasn’t gonna be ready for another year or so (on a large scale, globally). There is a SIMCOM module for LZTE-M (SIM7000C), with GNSS (GPS) and 2G but no 3G, but that is really new. My concern with LTE is that there are still lots of areas with no 4G coverage, so fallback to 3G seems necessary. Mark.
On 8 May 2017, at 2:18 PM, Dominik Westner <me@nikwest.de> wrote:
Isn't LTE-M the way to go? Something like the sequans monarch?
http://www.sequans.com/products-solutions/streamlitelte/monarch-lte-platform... <http://www.sequans.com/products-solutions/streamlitelte/monarch-lte-platform/>
On 8. May 2017, at 07:41, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
The side project of looking at 3G/4G modems has also started. This is going to be on one of those optional expansion slots to allow us to use different modems for different functions. I’m used to SIMCOM, but it seems their selection is getting complicated (particularly for 4G). I see the SIM5320A has 3G and GPS, which seems good but is quite dated now. SIM5320A:Dual-Band UMTS/HSDPA 850/1900MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320(J)E:Dual-Band UMTS/HSDPA 900/2100MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320J:Dual-Band UMTS/HSDPA 850(800)/2100MHz Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz It does have the CMUX, which is very nice (gives us four virtual ports over the single async port, so easier to deal with AT command control).
If anyone has any suggestions for the modem, it would be helpful. Something with GPS would be ideal.
Regards, Mark.
<OVMS_V3_Schematic_CN_20170503.pdf> <OVMS_V3_Layout_CN_20170508.pdf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
It is supposed to be rolled out across Europe over the next months. In US it already seems to be available. As this is a software only feature of the existing infrastructure it shouldn't take too long. But that information is only second hand. I'm mostly following what these guys are doing https://www.pycom.io/pycom-and-canonical-to-enable-lpwan-communications-via-... Sent from my iPad
On 8. May 2017, at 08:42, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
LTE-M
Is that ‘prime time’ already? I thought that wasn’t gonna be ready for another year or so (on a large scale, globally).
There is a SIMCOM module for LZTE-M (SIM7000C), with GNSS (GPS) and 2G but no 3G, but that is really new.
My concern with LTE is that there are still lots of areas with no 4G coverage, so fallback to 3G seems necessary.
Mark.
On 8 May 2017, at 2:18 PM, Dominik Westner <me@nikwest.de> wrote:
Isn't LTE-M the way to go? Something like the sequans monarch?
http://www.sequans.com/products-solutions/streamlitelte/monarch-lte-platform...
On 8. May 2017, at 07:41, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
The side project of looking at 3G/4G modems has also started. This is going to be on one of those optional expansion slots to allow us to use different modems for different functions. I’m used to SIMCOM, but it seems their selection is getting complicated (particularly for 4G). I see the SIM5320A has 3G and GPS, which seems good but is quite dated now. SIM5320A:Dual-Band UMTS/HSDPA 850/1900MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320(J)E:Dual-Band UMTS/HSDPA 900/2100MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320J:Dual-Band UMTS/HSDPA 850(800)/2100MHz Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz It does have the CMUX, which is very nice (gives us four virtual ports over the single async port, so easier to deal with AT command control).
If anyone has any suggestions for the modem, it would be helpful. Something with GPS would be ideal.
Regards, Mark.
<OVMS_V3_Schematic_CN_20170503.pdf> <OVMS_V3_Layout_CN_20170508.pdf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Both SIM7000C (LTE-M) and SIM5320 (3G) are available include GPS/GNSS functionality. Price of the SIM7000C is about 50% more expensive than SIM5320. They are very compatible at the pin level so not hard to support both. Longer-term LTE-M sounds good, but I think maybe too early for this today (even if networks available, how easy is it to get a data plan?). Regards, Mark.
On 8 May 2017, at 3:18 PM, Dominik Westner <me@nikwest.de> wrote:
It is supposed to be rolled out across Europe over the next months. In US it already seems to be available. As this is a software only feature of the existing infrastructure it shouldn't take too long. But that information is only second hand. I'm mostly following what these guys are doing https://www.pycom.io/pycom-and-canonical-to-enable-lpwan-communications-via-... <https://www.pycom.io/pycom-and-canonical-to-enable-lpwan-communications-via-snaps/>
Sent from my iPad
On 8. May 2017, at 08:42, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
LTE-M
Is that ‘prime time’ already? I thought that wasn’t gonna be ready for another year or so (on a large scale, globally).
There is a SIMCOM module for LZTE-M (SIM7000C), with GNSS (GPS) and 2G but no 3G, but that is really new.
My concern with LTE is that there are still lots of areas with no 4G coverage, so fallback to 3G seems necessary.
Mark.
On 8 May 2017, at 2:18 PM, Dominik Westner <me@nikwest.de <mailto:me@nikwest.de>> wrote:
Isn't LTE-M the way to go? Something like the sequans monarch?
http://www.sequans.com/products-solutions/streamlitelte/monarch-lte-platform... <http://www.sequans.com/products-solutions/streamlitelte/monarch-lte-platform/>
On 8. May 2017, at 07:41, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
The side project of looking at 3G/4G modems has also started. This is going to be on one of those optional expansion slots to allow us to use different modems for different functions. I’m used to SIMCOM, but it seems their selection is getting complicated (particularly for 4G). I see the SIM5320A has 3G and GPS, which seems good but is quite dated now. SIM5320A:Dual-Band UMTS/HSDPA 850/1900MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320(J)E:Dual-Band UMTS/HSDPA 900/2100MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320J:Dual-Band UMTS/HSDPA 850(800)/2100MHz Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz It does have the CMUX, which is very nice (gives us four virtual ports over the single async port, so easier to deal with AT command control).
If anyone has any suggestions for the modem, it would be helpful. Something with GPS would be ideal.
Regards, Mark.
<OVMS_V3_Schematic_CN_20170503.pdf> <OVMS_V3_Layout_CN_20170508.pdf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Interestingly, SIMCOM seem to be addressing compatibility. Here is an example: http://www.mt-system.ru/sites/default/files/documents/sim7100_sim5360_sim800... <http://www.mt-system.ru/sites/default/files/documents/sim7100_sim5360_sim800_compatible_design_v1.01.pdf> That covers making one board for SIM7100 (4G), SIM5360 (3G), and SIM800 (2G).
On 8 May 2017, at 7:36 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Both SIM7000C (LTE-M) and SIM5320 (3G) are available include GPS/GNSS functionality. Price of the SIM7000C is about 50% more expensive than SIM5320. They are very compatible at the pin level so not hard to support both.
Longer-term LTE-M sounds good, but I think maybe too early for this today (even if networks available, how easy is it to get a data plan?).
Regards, Mark.
On 8 May 2017, at 3:18 PM, Dominik Westner <me@nikwest.de <mailto:me@nikwest.de>> wrote:
It is supposed to be rolled out across Europe over the next months. In US it already seems to be available. As this is a software only feature of the existing infrastructure it shouldn't take too long. But that information is only second hand. I'm mostly following what these guys are doing https://www.pycom.io/pycom-and-canonical-to-enable-lpwan-communications-via-... <https://www.pycom.io/pycom-and-canonical-to-enable-lpwan-communications-via-snaps/>
Sent from my iPad
On 8. May 2017, at 08:42, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
LTE-M
Is that ‘prime time’ already? I thought that wasn’t gonna be ready for another year or so (on a large scale, globally).
There is a SIMCOM module for LZTE-M (SIM7000C), with GNSS (GPS) and 2G but no 3G, but that is really new.
My concern with LTE is that there are still lots of areas with no 4G coverage, so fallback to 3G seems necessary.
Mark.
On 8 May 2017, at 2:18 PM, Dominik Westner <me@nikwest.de <mailto:me@nikwest.de>> wrote:
Isn't LTE-M the way to go? Something like the sequans monarch?
http://www.sequans.com/products-solutions/streamlitelte/monarch-lte-platform... <http://www.sequans.com/products-solutions/streamlitelte/monarch-lte-platform/>
On 8. May 2017, at 07:41, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
The side project of looking at 3G/4G modems has also started. This is going to be on one of those optional expansion slots to allow us to use different modems for different functions. I’m used to SIMCOM, but it seems their selection is getting complicated (particularly for 4G). I see the SIM5320A has 3G and GPS, which seems good but is quite dated now. SIM5320A:Dual-Band UMTS/HSDPA 850/1900MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320(J)E:Dual-Band UMTS/HSDPA 900/2100MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320J:Dual-Band UMTS/HSDPA 850(800)/2100MHz Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz It does have the CMUX, which is very nice (gives us four virtual ports over the single async port, so easier to deal with AT command control).
If anyone has any suggestions for the modem, it would be helpful. Something with GPS would be ideal.
Regards, Mark.
<OVMS_V3_Schematic_CN_20170503.pdf> <OVMS_V3_Layout_CN_20170508.pdf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
We’ve come across a small power problem with the modem board. It seems that 3.3V is not enough for some of these modem modules, but ESP32 and SPI flash chips are sensitive to power so if we go too high we may run into problems with those. 3.6v is a compromise, but I’m concerned that if the power draw goes too high, voltage may drop too low for the modem. OVMS v2 used 4v (measured around 3.8v on a selection of OVMS v2 modules I have). Simplest solution seemed to be to route EXT_PWR (5v USB or 12v vehicle, whichever is bigger), USB_5V and EXT_12V through to the expansion connectors. Then, if the modem works on 3.3V fine we can just use that. Otherwise, we use EXT_PWR and a power supply just for the modem (tuned to whatever the modem requires). An alternative would be a DC booster, but that seems messy. Anyway, best to just route the power lines up to the expansion connectors and let us decide that later once we’ve had the ability to test it. If we want to tune the main AOZ1280 power supply output we can (it is just a resistor that sets the desired level). The revised expansion connectors shown on the schematic attached shows this new arrangement. One nice thing about this overall design is debugging the modem is simple. It is on it’s own expansion board with two single rows of pins. Easy to breadboard. We’re including a USB connector for direct manipulation from a PC (for debugging) - something like the serial port we had on OVMS v2. For the modem, it seems that one design of PCB will work with a number of different SIM5xxx (3G) and SIM7xxx (4G) modules. The attached schematic shows how that is wired. Nothing finalised yet - this first board with SIM5360 is just for initial testing and development. That said, the SIM5360 is a pretty nice 3G modem with three variants available for different frequency ranges. All have GPS/GNSS. It is a more modern version of the SIM5320 I played around with a year ago. Switch Mode power supply to 4V (from EXT_PWR so input maybe from USB 5V or 12V car). FXLA108 (or FXLA104 as we only need 3 bits) level shifter (1.8v <-> 3.3v). SIM socket (I suggest put this on top of board, and modem on bottom, to make easier to put in/out sim - or both on top depending on space available). Single internal blue LED for NETLIGHT status. Like OVMS v2 no need for this to be visible outside the case. I haven’t drawn it on the board, but perhaps we need a simple (internal only) push switch to toggle power (connected to MDM_EN circuit). Same as OVMS v2. A USB socket for debugging / firmware upgrade. No need for this to be visible outside the case. SIMCOM SIM5360(J)E (frequencies suitable for Hong Kong). GSM and GPS antenna. Regards, Mark.
On 8 May 2017, at 8:07 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Interestingly, SIMCOM seem to be addressing compatibility. Here is an example:
http://www.mt-system.ru/sites/default/files/documents/sim7100_sim5360_sim800... <http://www.mt-system.ru/sites/default/files/documents/sim7100_sim5360_sim800_compatible_design_v1.01.pdf>
That covers making one board for SIM7100 (4G), SIM5360 (3G), and SIM800 (2G).
On 8 May 2017, at 7:36 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Both SIM7000C (LTE-M) and SIM5320 (3G) are available include GPS/GNSS functionality. Price of the SIM7000C is about 50% more expensive than SIM5320. They are very compatible at the pin level so not hard to support both.
Longer-term LTE-M sounds good, but I think maybe too early for this today (even if networks available, how easy is it to get a data plan?).
Regards, Mark.
On 8 May 2017, at 3:18 PM, Dominik Westner <me@nikwest.de <mailto:me@nikwest.de>> wrote:
It is supposed to be rolled out across Europe over the next months. In US it already seems to be available. As this is a software only feature of the existing infrastructure it shouldn't take too long. But that information is only second hand. I'm mostly following what these guys are doing https://www.pycom.io/pycom-and-canonical-to-enable-lpwan-communications-via-... <https://www.pycom.io/pycom-and-canonical-to-enable-lpwan-communications-via-snaps/>
Sent from my iPad
On 8. May 2017, at 08:42, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
LTE-M
Is that ‘prime time’ already? I thought that wasn’t gonna be ready for another year or so (on a large scale, globally).
There is a SIMCOM module for LZTE-M (SIM7000C), with GNSS (GPS) and 2G but no 3G, but that is really new.
My concern with LTE is that there are still lots of areas with no 4G coverage, so fallback to 3G seems necessary.
Mark.
On 8 May 2017, at 2:18 PM, Dominik Westner <me@nikwest.de <mailto:me@nikwest.de>> wrote:
Isn't LTE-M the way to go? Something like the sequans monarch?
http://www.sequans.com/products-solutions/streamlitelte/monarch-lte-platform... <http://www.sequans.com/products-solutions/streamlitelte/monarch-lte-platform/>
On 8. May 2017, at 07:41, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
The side project of looking at 3G/4G modems has also started. This is going to be on one of those optional expansion slots to allow us to use different modems for different functions. I’m used to SIMCOM, but it seems their selection is getting complicated (particularly for 4G). I see the SIM5320A has 3G and GPS, which seems good but is quite dated now. SIM5320A:Dual-Band UMTS/HSDPA 850/1900MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320(J)E:Dual-Band UMTS/HSDPA 900/2100MHz, Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz SIM5320J:Dual-Band UMTS/HSDPA 850(800)/2100MHz Quad-Band GSM/GPRS/EDGE 850/900/1800/1900MHz It does have the CMUX, which is very nice (gives us four virtual ports over the single async port, so easier to deal with AT command control).
If anyone has any suggestions for the modem, it would be helpful. Something with GPS would be ideal.
Regards, Mark.
<OVMS_V3_Schematic_CN_20170503.pdf> <OVMS_V3_Layout_CN_20170508.pdf> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
participants (7)
-
Collin Kidder -
Dominik Westner -
Edward Cheeseman -
HONDA S-2000 -
Mark Webb-Johnson -
Michael Stegen -
Stephen Casner