This installment will cover a continuation of my exploration into tank resonances, interfacing the Nucleo MCU and GPS decoding.

I have been trying a lot of things to try and figure out if it is possible to use acoustic resonance to determine fuel level in a gas tank. You can see some of the experiments here:

Gas Tank Resonance

There is some promising results that seem to indicate the air resonance is well below other resonances, so maybe a simple low pass filter will help to isolate them. However, it would seem my piezo actuators can't excite these low frequencies so I have to get some new drivers. I will try some drivers used to convert flat surfaces into speakers, but they may take a while to arrive.

 

GPS

There are lots of other tasks to address in the mean time. My system will need GPS data to determine location and time. I don't know yet if there is already a Nucleo library to parse GPS (NMEA) data, but I have been looking into the NMEA sentence structure from my particular GPS module (UBLOX NEO 6M) in preparation for tackling the parsing task:

National Marine Electronics Association (NMEA) sentences always start with a "$" character and can be up to 80 characters long. If the sentence is from a GPS module, the next 2 characters are always "GP". The next 3 characters indicate what type of information is in the message. There are about 29 types of message. The UBLOX module I have generates at least 5 or 6 types of sentence and strings them all in burst each second.

The RTB2004 scope was very helpful in capturing NMEA ASCII sentences without doing any hardware or software and it was instrumental in discovering which types of NMEA sentence my UBLOX module was generating. One thing this data shows is the module starts sending NMEA sentences immediately on power up - long before it has a GPS lock, and these messages are abbreviated. It appears the GPS module sends what data it has, but if there is a dropout, it will still send partial data, so a parser needs to be able to handle partial dropouts of data without getting confused.

 

MCU

The Nucleo-L476RG has lots of flexibility in power supply arrangements but careful attention must be paid to correctly jumpering the system for the desired power scheme

 

System Peripherals - LoRa, GPS, LCDs, Accelerometer, Gas Tank Sensor

Besides the gas tank sensor and the GPS, my system also needs a LoRa radio, a couple of LCD displays and an accelerometer (tilt sensor). I have been really struggling to get this functionality into the Nucleo paradigm. I made a pinout list for all the modules supplied in the challenge kit and discovered a lot of conflicts as can be seen in the table below. Multiple cards use the same pins and this gets far worse when I add in the extra functions my system needs. Some of the cards have jumpers to allow alternate pins for some pins, but there are still too many conflicts to resolve easily. All of the expansion cards supplied in the kit use only arduino pins - which are of course supported by the MCU, but there just aren't very many pins in the arduino standard. The LoRa card I purchased from ST Micro also uses only Arduino pins. It would seem to me that all Nucleo cards should use Morpho connectors and leave arduino pins free for arduino shields. This way ST Micro could control the pin conflicts with their Nucleo cards and allow arduino cards to be used as well. The way it is now, there is no way to fit an arduino card into the system if you use the Nucleo Wi-Fi module or the LoRa module, there are just no pins available, except maybe the I2C bus. The LoRa module even clobbers the arduino SPI pins, making the SPI bus useless. However there aren't enough pins left over to use as chip selects anyway, so it is problematic on multiple fronts.

 

NucleoNucleo-L476RG ArduinoSensorsWi-FiBluetoothLoRaLCD1LCD2GPSFuel Sensor
FunctionMorpho
CN7
Morpho
CN10
FunctionArduino
CN5
Arduino
CN6
Arduino
CN8
Arduino
CN9
IKS01A2IDW04A1IDB05A1LRWAN1
PC101TX
PC123
VDD5
BOOT07
NC9
NC11
PA1313
PA1415
PA1517
GND19
PB721
PC1323
PC1425
PC1527
PH029
PH131
VBAT33
PC235Analog
PC337
PC112RX
PD24
E5V6
GND8GND
NC10NC1
IOREF12IOREF23V3+3V33.3V
RESET14RESET3RESETRESETRSTRST
+3V316+3V343V3+3V33.3V3.3V3.3V3.3V
+5V18+5V5+5V
GND20GND6GNDGNDGNDGNDGNDGNDGND
GND22GND7GNDGNDGNDGNDGNDGNDGND
VIN24VIN8VIN
NC26
PA028A01USART_CTSIRQLED
PA130A12USART_RTSCSNADC_IN8
PA432A23LSM INT/DRDYSPI_IRQLSM_INT
PB034A34LSM INT/DRDYWAKEUPLSM_INT
PC136A45INT2 (DIL24)SPI_CSLSM_DRDY
PC038A56INT1 (DIL24)SPI_CsxLSM_DRDY
PC91
PB83D1510SCLI2C_SCLI2C_SCL
PB95D149SDAI2C_SDAI2C_SDA
AVDD7AVDD8
GND9GND7GNDGNDGNDGND
PA511D136SPI_CLKCLKSCKSCK
PA613D125SPI_MISOMISOMISOMISO
PA715D114SPI_MOSIMOSICOMP1_INPMOSIMOSI
PB617D103WAKEUPxCSNCOMP1_OUT
PC719D92SPI_IRQIRQD/CD/C
PA921D81USART_TXnSRCC_MCO
PA823D78WIFI_RSTRSTSYS_WKUP1
PB1025D67LPS22H INT1HTS_DRDY
PB427D56LSM6DSL INT2LPS_INT1
PB529D45LSM6DSL INT1HTS_DRDY
PB331D34CLKLPS_INT1
PA1033D23USER INTSCESCE
PA235D1 (TX)2UART_RXRX
PA337D0 (RX)1UART_TXTX
PC82
PC64
PC56
U5V8
NC10
PA1212
PA1114
PB1216
PB1118
GND20
PB222
PB1024
PB1526
PB1428
PB1330
AGND32
PC434
NC36
NC38

You can see from this chart that all the unused pins are on the Morpho connectors.

 

Fortunately the LoRa card has accelerometers on it, so I don't need the sensor card in the kit and I can live without the Wi-Fi card if the LoRa card works out.

I really only need the LoRa card plus a custom card I am making that has 2 SPI LCDs and a UART GPS. Unfortunately, the LoRa card uses the SPI pins (but not for for SPI) and it also uses the arduino UART pins. And it dosen't leave 2 spare pins for chip selects on the displays.

The next alternative would be to make a Morpho card that connects my peripherals to the Morcho connectors. Unfortunately the LCDs need to be on top to be visible, but the LoRa card does not pass the Morpho connectors through. This would require ultra long pins to go around the LoRa card - I don't have any and don't know of any and am not sure about this as a solution for an off-road motorcycle in terms of ruggedness.

So what about putting the LoRa card under the MCU and the LCD card above the MCU? Well unfortunately, the arduino connectors on the MCU are not stackable on the underside. (The Morpho connectors are stackable on both sides).

So where does this leave me?

Well I see 3 possible avenues:

  1. surgical intervention
    • cut and jumper traces on the LoRa card to make pins available for the displays and GPS. This is a non-starter - there is not enough information available on the LoRa card to make this option feasible in the time frame available.
  2. kludge wiring everything together
    • For me this really detracts from the appeal of the project. I design PCBs for my projects to that all the work I put into the project can be leveraged in future projects. This option is still on the table because I feel an obligation to get something working, but it really rubs me the wrong way.
  3. use 2 Nucleo systems
    • I could make a custom card for the clock and the gas tank sensor and a separate system for the LoRa, GPS and accelerometer. This is technically feasible but has a number of drawbacks:
      • the GPS will still need to be kludged onto a Morpho connector
      • both systems would need a GPS receiver - one for location and one for time
      • The two systems will be much bigger and uglier and harder to mount on a motorcycle
      • I would have to invest more money in a second system which at the same time will end up being less rewarding.
      • It will be even harder to get the LoRa capability working without a display to show status.

I have already partly completed the custom interface schematic and PCB layout for the displays and GPS so I have to make some critical decisions very soon.

 

Summary for this week

Lots of leg work going on but progress is meager relative to the effort. The resonance investigation is interesting but the technology is a long way from being viable at this stage. The system design has a frustrating number of roadblocks that are slowing progress, but I'm learning a lot. With some projects the main value comes from the lessons learned.

 

Project Links:

IoT On Wheels Design Challenge page

 

 

Links to other blogs on this project are included in the first blog:

https://www.element14.com/community/community/design-challenges/iot-on-wheels/blog/2017/09/21/the-konker-connection-blog-1