BasicPI

SPI is a very powerfully and fast serial port used between Master and one or more slaves, but I want to evolve the bus into a proper device to device bus. This is actually far more straight forward than I expected as both Raspberry PI and STM32F405 support Half-Duplex modes. RPI only support Half-Duplex Master, so all I need to do is to connect MISO and MOSI and set correct modes – Raspberry PI into Half Duplex Master and all STM32F405’s into Half-Duplex Slaves. Switching between sender is done in SW using a Dynamic time-slot scheme.

Doing this without Raspberry PI can be done in the same way by one of the devices taking over as Half-Duplex Master. The key here is that we have connected full SPI, MOSI to MOSI and MISO to MISO, but in Half Duplex one of them will be idle so we just connect them together. This should work!

F405 is capable of 42Mbps, but the closest RPI speed is 32Mbps – and if we assume 1ms switching time and max 4ms sending we should be around 25Mbps (80%) effective bandwidth usage.

This is a step down from 84Mbps bandwidth on a full duplex (F405), but it is still pretty good speed and very functional since we now communicate device to device directly.

The second scheme that I used before is using full duplex and using a dynamic time-slot scheme between device that send on MISO. This works very well, but I can only send to/from Master – never directly Device to Device in this scheme. This mode have the advantage of full duplex, meaning that with the same 32Mbps and 80% rule we have a 54Mbps total bandwidth. But, is this actually faster? The answer depends on your message flow – if all your traffic is to/from the Master then yes, if not we just waste bandwidth by turning messages around at master.

A 3rd Scheme of rotating Master is possible, but I fail to see what I would gain since changing Master means all communication goes through that device.

All my new Hat’s have full SPI connected and to enable Half-Duplex mode we simply add a jumper between MOSI and MISO on the header – this enables me to select communication scheme based on what I believe is most efficient.

Half-Duplex with STM32F405’s only will be at 42Mbps and as with ca 34Mbps effective bandwidth. We get lower speed with Raspberry PI because we need to fit available clock schemes with this as Half-Duplex Master.

Assuming we have 20 devices in a stack the max message wait time will be 5ms x 20 under full load which is 100ms. I am ok With that because this is a very worst case – I actually believe switch time is much much lower and we can improve parameters, but we can measure that later.

So how much bandwidth do we need for stereo sound? Assume that sound is 32 bit samples at 32Khz – this is 1Mbps bandwidth usage. This is a brute force calculation, but it still indicate that we have bandwidth for 25-50 channels of high quality sound. If I assume telecom quality which is 64Kbps we basically have capacity for ca 195 2-way phone calls simultaneously.

Doing video or sound over some distance is more of an issue, but don’t forget that we have Wired and Wireless Ethernet options as well.

To sum this up – I intend to abandon my attempt on rotating Master and focus on 2 schemes – Master with dynamic TDM slots on Slaves or Half-duplex with dynamic TDM slots that scale to load. I will be back with a more detailed protocol description later.

I finished the LoRa + GPS w/E22-900M30S earlier today and decided to add in E22-900M22S footprint. The modules are almost identical except in size. The only difference is that 30S have pin 10 to 3.3V while 22S have this to ground, so it is straight forward to have both footprints on the PCB.

The 3D model show the 22S module and illustrate well the size difference to the stronger 30S module. This enables 4 LoRa units:

• E22-400M30S, 433Mhz, 1W, 12km range
• E22-900M30S, 868Mhz, 1W, 12km range
• E22-400M22S, 433Mhz, 0.1W, 6.5km range
• E22-900M22S, 868Mhz, 0.1W, 6.5km range

All modules have an IPX antenna on the module, so I use a PCB antenna with wire to the IPX. This provides a PCB antenna option, but I can also use the IPX directly for more options.

As for the range listed above – this is datasheet numbers. It will be line of sight mostly and I expect somewhere between 2-6.5km for 22S. As for the stronger maybe 5-12km. I say this because E22 modules give very optimistic range data, but we will see.

1. IPX Antenna for LoRa directly on the module.
2. PCB Antenna for LoRa.
3. Power leds + MCU Status.
4. USB Connector for MCU.
5. Separate Power connector.
6. GPS Module. Can use NEO-6M, NEO-7M or NEO-8M.
7. GPS Antenna.
8. USB for GPS Module.
9. UART TTL.
10. SWD
11. STM32F405RG. Powerfully ARM M4 capable of running MicroPython.
12. Raspberry PI Connector.
13. CAN Port.
14. LoRa Module. 1W or 0.1W in 433/868Mhz area capable of up to 12km with up to 300kbps data-rate.

This board can function stand-alone, as part of a CAN stack or as a Raspberry PI Hat. LoRa and GPS can be switched off through separate power supplies.

This is a LoRa and GPS Hat. The larger E22-900M30S with a range of 12km at left and the small NEO-6M at right. NEO-7M and NEO-8M should also work.

I mistook NEO-6M for having a SPI interface, but realized this was for Flash/EEPROM.

I replaced coils normally used to separate frequency interference with 3 x SPX3819. One for the MCU and one for LoRa and one for GPS with Enable pin controlled from the MCU. This way I can switch modules on/off through power. I need to double-check peak power consumption on E22-900M30S, but SPX3819 supplies 500mA so I hope this is sufficient.

This is the first mock-up with the LoRa unit on. This is the larger and stronger of the modules and it occupied a bit more place than I expected, but I will do. It’s not much passive components on these modules and I still think I have just about the space for the GPS and antenna on right side. We will see tomorrow as I make the package. 

The E22-900M22S is about 1/4 of the size. They are based on the same chip, but 30S got a stronger 1W sender. 22S uses 0.1W and cover 6.5Km according to its datasheet. I take those 12km and 6.5km with a pinch of salt. At these frequencies this will be at line of sight, but lets test.

As for my 3D models I am very accurate with PCB footprint, but the rest is as far as I go an illustration. The antenna as an example show the space it will occupy, but it lack details. You can sit days fiddle with these if you want to, but I prefer them simple and editable.

Packing a LoRa and GPS module on the same Hat should be possible and make a lot of sense. I could pack a battery manager as well, but I rather just make a separate board with battery on and this can be stacked on the back of this unit anyway.

The MCU is the classic STM32F405RG which have 3 SPI’s and I will use all 3. One for RPI, One for LoRa and one for GPS.

LoRa is E22-900M30S with a huge range, programmable sending power and frequency selection. This is based on the SX1262 RF chip. I have no experience with this, so I have ordered various units to start with. This unit is a bit large so it will occupy most of the left half. Luckily this has a IPX antenna so we don’t need to worry about antenna wiring.

NEO-6M, NEO-7M and NEO-8M are GPS modules that are very small. I will be using NEO-6M, but NEO-7M and NEO-8M are backward compatible, so we can upgrade and check those later.

This board is straight forward. Most of the work is actually to make the packages for the LoRa and GPS module.

I decided to add the Hat form and RPI connection to my Hat allowing me to use this as a PSU as well. I need far more powerfully PSU’s than this, but TPS54260 can deliver 2.5A on any voltage I need, so it’s a beginning + its 3 voltages coming from this board so why not.

This is an easy change since it cost nothing extra. I could have made this board much, much smaller as well, but who cares. The purpose here is to test TPS54x60 circuits – the rest is freebies.

TPS54x60 is a very nice DC/DC converter covering up to 60V, but the circuit I used on the MC3X60V3A Motor Driver snapped at 30V+. I tested with 2 units before consulting a friend that suggested to add a 10uF capacitor very close to VIN. I have yet to test this because I did not want to sacrifice the one unit I had working. But, I need this 60V DC/DC working because I am using it elsewhere, so I decided to make a separate test PCB to Experiment with..

Reading the data-sheet for the TPS54160 I think my fiend might be right, but I am also curious about the EN pin. I left this floating which should be ok, but I need to test this. The last bit is the PWRGD pin which basically should drive a Led or something if power is ok.

Having a special breakout for this makes sense because this is a good circuit for experimenting with values for various voltages. For 24V I can as well do with a simpler linear regulator, but this is excellent for 48V. Yes it says 60V, but as I have explained before using a DC/DC converter at it’s limits with a motor controller involved is asking for trouble.

The next bits I want to add is 5V and 3.3V linear regulators fed from the 12-16V from the DC/DC.

The 3.3V have an enable that can be tied to VIN or driven by an external MCU pin. It also have a 0.33F Super Capacitor. This circuit should deliver 3.3V at 500mA.

The 5V circuit is identical, but do not use the Super Capacitor. I sometimes need 5V in addition to 12V and 3.3V, and the small SPX3819 deliver 0,5A from a SO23 packet making it an ideal small and low cost alternative.

The form factor of this board is a bit big, but the objective is only testing of the DC/DC so that is ok.

SIM7020E is a small module that offer 4G services and access to the new NB-IoT service that is available to give access to remote sensors that earlier was not possible. All-in-All this is just a new wrapping on a service that have been available since GSM and can be achieved with several low cost modules. The difference with NB-IoT is that is support better latency/cost schemes.

I really would have preferred to put 4G, GPS and LoRa on one Hat, but I will run into space and antenna issues so the 4G module will be on it’s own.

PSU requirement for SIM7020 is 500mA power peak, but this should be achievable through standard PSU. At some point I need to add a PSU module supporting my Hat’s, but that is for later concerns. To support the power and avoid a power dip I added space for a 0,33mF Supercap on the 3.3V. This should significantly reduce the peak current + the hole-though connectors can actually be used for a battery as well.

Debug is through USB or UART2, Firmware upgrade is only UART2 – a bit weird, but I have added both. Powering either of the USB’s will power everything to allow debug as needed with a single USB. ESD protection is added for VBAT (3V+, SIM card lines and UART2 lines.

This is my 7th Hat in the new format. I had no reference on the SIM7020E schematics, so will be exiting to see if this works at all. Was a bit annoyed over the UART’s from SIM7020E because they where 1.8V, so had to add a level shifter. Used TBX0108 in SO20 format from Texas Instruments, so will see how that goes as well. Luckily I have a test board on the way so I get to test NB-IoT before I dig into my own board.

Functionality on NB-IoT uses a STM32F405RG to either connect on USB, SPI to Raspberry PI or CAN. Connection to SIM7020E is through UART on TTL level. Both UART’s are level shifted. The external UART is for Programming/Debug, while the extra USB also id for Debugging.

I have no experience using these modules, but I expect that I will be able to send/receive data using TCP/UDP at a speed of 26.15-68.5Kbps. It will be interesting to test.

Next out is GPS and LoRa Hat’s.

1. Hall sensor logic
2. 60V DC/DC Converter
3. Gate Drivers
4. Raspberry PI Connector
5. MCU
6. SuperCap for 3,3V on MCU
7. Raspberry PI mount holes
8. Mount holes for heat-sink
9. Leds
10. SWD
11. USB
12. 2 x End point sensors
13. PSU Capacitance
14. CAN port
15. +60V
16. MOSFET Array
17. GND
18. Extra GND Connectors
20. Current Sensors
21. Phase output
22. 2 x Temperature Sensors.