The Konker Connection - Blog 3

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

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

Rohde & Schwarz RTB2K-COM4 Digital Oscilloscope - Review The Konker Connection - Blog 3

Poster

Upload Preview

Ok

Cancel

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:

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

Rohde & Schwarz RTB2K-COM4 Digital Oscilloscope - Review The Konker Connection - Blog 3 Design Challenge Project Summary #33: The Konker Connection

Poster

Upload Preview

Ok

Cancel

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.

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