Skip navigation
1 2 Previous Next

IoT on Wheels Design Challenge

17 Posts authored by: dougw Top Member

This blog is a continuation of the Konker Connection project. As luck would have it, the accelerometer module did not arrive until one day after the design challenge ended. However that isn't going to stop the project from proceeding. The accelerometers are intended to indicate the tilt angle of the motorcycle and this video demonstrates the accelerometers installed, programmed and functioning in various tilt positions:


Project Links:

IoT On Wheels Design Challenge page


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

This project has been a marathon of exploration and learning, ending up with a whirlwind of blogging and trying to document the project. I have been at it non-stop for 3 days now and I have not had any time to reflect back on the project. However, I wanted to get some preliminary thoughts down before the project closes. I will likely add more later if I realize my initial material is missing key points.

In my proposal, I kept the goals pretty simple, or so I thought. There was nothing easy about this project, despite being supplied with a great kit of powerful hardware..

I had put in a couple of stretch goals that were too risky to promise results but were of great interest to me  - set up a LoRa radio system and try to measure fuel level using acoustic resonance. These type of extra goals that take you into unknown territory are one of the most beneficial aspects of these design challenges and I am glad I tackled these particular technologies in this challenge.

I had mixed success on both fronts but looking at it as a learning journey, exploring the Nucleo environment and the stretch goal technologies, it turned out to be a most enjoyable project. There is a lot of satisfaction in tackling hard things - even just finding out you have the perseverance to dive in and press forward when things are not working well is worthwhile. I definitely maxed out on effort, sometimes to the detriment of spending time blogging.

What I did accomplish though was a very nice Nucleo L476RG mobile instrumentation platform that fits well on my motorcycle. The case has lots of room for more sensors and electronics and the Nucleo MCU has tons of horsepower to handle more tasks.

I would like to profusely thank element14 and STMicorelectonics for sponsoring this this very topical design challenge - it has provided wonderful motivation to tackle interesting and difficult technologies. Encouragement and interaction from other element14 members was a special benefit of this forum and it really adds to the enjoyment factor.

Project Links:

IoT On Wheels Design Challenge page


Project Stats:

  • 16 blogs
  • 18 videos
  • 1 custom PCB
  • 1 gigantic amount of learning


Links to other blogs on this project:

The Konker Connection - Blog 1

The Konker Connection - Blog 2 - Fuel Sensor Concept

The Konker Connection - Blog 3 - GPS data

The Konker Connection - Blog 4 - Custom PCB

The Konker Connection - Blog 5 - First Program

The Konker Connection - Blog 6 - muddling along

The Konker Connection - Blog 7 - GPSWOX

The Konker Connection - Blog 8 - 1st LCD Test

The Konker Connection - Blog 9 - GPS Demo

The Konker Connection - Blog 10 - Dual LCD Demo

The Konker Connection - Blog 11 - GPS Clock & Position

The Konker Connection - Blog 12 - Mechanical Design

The Konker Connection - Blog 13 - System Assemby

The Konker Connection - Blog 14 - The Walk Around

The Konker Connection - Blog 15 - Micro Road Trip

The Konker Connection - Blog 16 - Wrap-up Discussion

Here are some pictures showing how all the parts fit together.


The rider view





Project Links:

IoT On Wheels Design Challenge page


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

To get the Nucleo System installed reliably on my motorcycle required a pretty intensive mechanical design effort, but a primary objective was to get the system mounted on wheels, so it was necessary.

I first designed a snug-fitting 3D printed bracket to mate the electronics case to the bike. This bracket actually sits on the saddle extension that rides up on the gas tank. It involves a complex multi-curvature saddle shape that stretched my CAD abilities:


Next I designed a base case for the electronics and battery:


Finally I designed a deck with a dome window to protect the electronics while allowing the LCDs to be viewed:


The next blog will show some pictures of how this all fits together.


Project Links:

IoT On Wheels Design Challenge page


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

This blog demonstrates the Nucleo instrumentation platform operating in harmony with motorcycle operations.


The Nucleo is on wheels!


Project Links:

IoT On Wheels Design Challenge page


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

This is a quick video showing where the Nucleo system is installed.


Project Links:

IoT On Wheels Design Challenge page


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

This update shows the Nucleo L476RG displaying GPS clock and position data on a pair of Nokia 5110 LCDs. Both the GPS and the LCDs are connected to the Nucleo module by a custom PCB which also incorporates a 3-axis accelerometer (which has not arrived yet) plus some switches and audio circuitry for a fuel level sensor. The electronics system is now a fully functional development platform for mobile sensors based on a powerful Nucleo Cortex M4 MCU, running off its own Lithium battery.

I struggled more than I really want to admit to get the firmware working properly, but it is now stable and doing what it is supposed to do.

This is another short update as I am still immersed in trying to get more done, but it represents a huge milestone - electronics and firmware tested and working.


Project Links:

IoT On Wheels Design Challenge page


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

My custom interface PCB finally arrived after flying around the planet for a month.

It is very late in the project to be just starting to build interfaces, with lots of software development still required, but you have to play the cards you are dealt, or in this case, build the cards when you get them.

I will have to also find time to squeeze in some blogs so here is a quick demo of the system running its first dual LCD software:


It is always highly gratifying when a new card works perfectly on the first try, and it is critically important to get it right when there is no time or money to spin the design.

This project seems to go much better when I'm working on the aspects I have designed.....Other designers' software in particular seems to throw me for a loop....


Project Links:

IoT On Wheels Design Challenge page


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

The past few weeks have been a grueling exercise of long hours trying to achieve some tangible progress. I spent days scouring the internet for information and software that might help get the LoRa expansion card working, and then more days trying to get software and libraries properly installed and configured. I was running through a large number of installation variants which were not useful and not documented. I figured when I got something working I would document that, but I never really got the compiler to accept the code I wanted to run. I then tried hacking away at the code to see if I could at least get some functionality running and had my usual problems trying to understand what all the code was really doing. The software in question was not even everything I wanted – it was just a start and had only two main purposes:

  1. to read and parse the GPS radio
  2. to send GPS data via LoRa radio

After getting everything loaded up as optimally as the documentation was able to suggest, the compiler was still complaining that the standard SPI calls to communicate via the Nucleo's arduino SPI pins were not legal. I eventually found some gossip on the internet that indicated the Nucleo arduino IDE has not implemented SPI yet. That is pretty much a show-stopper as the LoRa radio software uses SPI to talk to the local host. There are still some avenues to explore, such as trying to precisely mimic the arduino SPI calls with a bit-banging implementation of SPI. Or it might be possible to get the LoRa radio to use a different communication method, but then I would probably have to write all the LoRa protocols from scratch. That is all pretty daunting for me given how many problems I am having. I really hope SPI gets implemented soon so I can use this powerful Nucleo MCU with this LoRa module.

Eventually I chopped out the LoRa code and just tried to get the GPS working. After much tweaking I finally got the compiler to stop complaining and actually had a clean compile. However there was no GPS data being detected, so I checked it out with a scope and the GPS data was definitely sending good data every second as it was supposed to do. My scope can decode GPS messages and they were definitely solid.

I then discovered that the standard serial pins on the Nucleo's arduino connector were not connected to the MCU. This info is documented in the Nucleo user manual, but of course I had made an erroneous assumption that the arduino pins were all connected. It turns out this port is used to program the MCU and is connected to the programming co-processor which uses the USB port. When I first discovered this I thought maybe it was like an arduino leonardo (which also has an on-chip USB port designated as the Serial port) where the standard serial pins could be accessed using Serial1 instead of Serial, but that is not the case.

There are 2 zero ohm jumpers connecting the Tx and Rx of the co-processor to the MCU which can be removed, and 2 sets of open jumper pads to connect the arduino Tx and Rx pins to the MCU, but if all these jumpers are configured for arduino serial communications, the ability to program the MCU is defeated.

Since the GPS is simply blasting out a data burst once per second, I only need the transmit pin connected. I removed the zero ohm jumper from the programming transmitter and replaced it with a 10K resistor. This way I don't need to re-solder the jumper every time I want to reprogram the MCU – I simply remove a jumper on the GPS transmit pin. Even if both transmitters are active and connected at the same time they see no more stress than a 10K resistor load. In ths scenario the GPS will control the pin and not be influenced by the programmer.

This arrangement was extremely important because I am going through an enormous number of reprogramming cycles and re-soldering jumpers every time is out of the question.

After I had the serial port hardware setup properly the MCU could be programmed easily, but the GPS data was still not being recognized by the GPS library calls. A further few days of hacking on the code did not result in any significant progress, so I decided to just write the GPS parsing software myself.

I still went though a massive number of iterations trying to get my parsing code to reliably extract the clock and GPS coordinates, but at least it was all under my control and there was nobody else to blame.

Based on the amount or work it took to get this far, it should feel like a big accomplishment, but the reality is it should have been a pretty straightforward exercise. Where it stands right now is my software can read and parse GPS data to get clock and location and display it on a local LCD.

I am learning a little about what to do and a lot about what not to do, but at least there is some tangible progress.


Project Links:

IoT On Wheels Design Challenge page


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


This project is still experiencing lots of software issues and some parts have not arrived yet, but time is running short and the project needs to move ahead. My custom PCB interface card is taking a very long time to arrive. It shipped by air 20 days ago and doesn't even look like it has made it into Canada yet - that is one very slow aircraft.

For this blog, I have been forced to use a breadboard, but at least I am programming the Nucleo, and since this part of the project is all my own code, I am having a much easier time getting it running the way I want.


Project Links:

IoT On Wheels Design Challenge page


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

Baby steps.... I've been lost in "a maze of twisty little passages" at the end of a long rat hole ... trying to set up my back-end infrastructure to  where my LoRa gateway sends GPS data across the internet to get plotted on a map accessible from any browser.

I am using a Dragino LoRa gateway which is now (after many false starts and much head scratching) setup with a WAN ethernet connection to my internet router.

In addition to its LoRa gateway role it is also acting as a Wi-Fi hotspot. It has a web server to allow setup:

And I can use SSH over WiFi to force it to perform tasks like sending GPS data.

For a while there, I thought I had bricked the device - it wasn't communicating at all. This wasn't really the fault of the hardware, just my ignorance on several levels.

I still have not got the right code compiling on either the client or the gateway, but I can tell the gateway to send GPS data to GPSWOX and have it plotted on a map.... baby steps...


This map is a screen capture of my browser showing a (green) track of several locations I had the gateway send to GPSWOX that describe a rectangle in my city.


Project Links:

IoT On Wheels Design Challenge page


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

This blog is really just to indicate I have been working on the project. However there is not much visible progress to report.

I have got the arduino IDE working with the Nucleo MCU and I can write programs for it that work, but 3rd party arduino programs don't necessarily work.

I have a LoRa Gateway (Dragino) set up and communicating via SSH and its own web server.

I have a GPSWOX account setup to do real time GPS tracking on a map.

The LoRa client is supposed to read formulate and send GPS data to the LoRa gateway which then passes the data to GPSWOX to plot on a browser map.

But they are not communicating yet - all kinds of issues getting supposedly working code to compile properly.

I have loaded up a bunch of libraries and code to do LoRa client and LoRa gateway, and GPS parsing.

I have plugged the LoRa client card onto the Nucleo MCU but the code for that is also not compiling.

There seem to be compatibility issues between arduino and the Nucleo port. For example the software serial port library doesn't work because the Nucleo runs at a different clock rate from normal arduinos.

I have been re-writing some of the source code, but have not been able to bypass all the issues yet.

Needless to say the LoRa client and gateway are not yet talking either.

My custom PCBs have shipped but not arrived yet.

My main nemesis (understanding other programmer's software) is in a full court press right now and there is not much light up ahead, but I am still working on it. Apologies for not spending a lot of time on the blog, but I need to spend lots of time on getting stuff working. Hope some things start to work a bit better soon.....


Project Links:

IoT On Wheels Design Challenge page


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

I have been plugging away at trying to match enough hardware to this MCU to achieve the functionality I want.

Some would say resistance is futile,

some would say persistence is fertile,

I would just say persistence takes a while.

Currently I found a card that has a LoRa radio and a GPS, from Dragino, that should fit with both the Nucleo MCU and my custom card.

The Dragino card is an arduino compatible card and there is some arduino software that runs it - if I can port it to the Nucleo.

Fortunately ST Micro has been working to get their STM32 cores into the arduino board manager. The instructions on how to install STM cards in the arduino IDE are located here. If you are familiar with arduino programming you can dramatically step up performance with this 80MHz 32bit Cortex M4 platform (1 Mb FLASH, 128Kb SRAM, 12bit ADC)

Here is a short video demonstrating that the arduino IDE works fine with the Nucleo L476RG - one big hurdle cleared:

Blinking LEDs is not usually a big deal, but it represents getting the software development system working properly with the target platform and I am extremely happy to reach this milestone.

My custom expansion card with LCDs and sensors was designed before I settled on this solution, but luckily the pinouts are quite compatible. The main problem might be that the LCDs cover the GPS antenna, so I may need to mount an external antenna. (there is already a convenient connector for this scenario)

Now I can start diving into software development. There are still significant risks and uncertainties remaining, not to mention lots of work, but I am light years ahead of where I was when I had no fully functional design.

This has been a short update but lots of work went into clearing a major pin conflict roadblock and an important development system milestone has been achieved.


Project Links:

IoT On Wheels Design Challenge page


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




This project needs to start making serious headway against the issues that have presented themselves. First up - the gas tank level sensor technique I am exploring is showing a little more promise after a concerted effort. I procured a surface speaker exciter to try and generate vibrations at lower frequencies. This driver was able to excite much lower resonances than the original piezo disk and the low frequency resonances were proportional to air volume in the tank (bottle). Persistence is paying off, but progress needs to accelerate.

I also did a meticulous test of resonance due to blowing across the top of the bottle versus fluid level. This also yielded a proportional relationship between resonant frequency and fluid level. However the actual resonant frequencies from the two different methods of excitation were not the same at the same fluid level - not even close. I suspect the bottle nozzle geometry interacts with the air volume or rather the air volume adjusts the natural vibrations of the nozzle. This unfortunately means I can't use the blown air technique to calibrate resonance versus volume.

Here is a video demonstrating the surface speaker exciting resonances in the bottle:

Actually detecting resonance in a real tank with a microcontroller is going to be difficult based on my findings so far - the resonance frequency is not strongly dependent on air volume, so the numbers fluctuate quite a bit and accuracy is not high, even under very controlled conditions. None-the-less I need to get my interface card on order, so I will just have to make a best guess as to what circuitry might work and get it on order.

As side note for those interested in surface speaker driver technology - here is a demo of the surface exciter working as a speaker playing a song from the radio:

Up next I had to tackle the issue with designing an interface card to implement the features of my design. The expansion cards in the challenge kit were really not playing well with each other or the functionality I wanted to implement, there were heavy pin conflicts with multiple cards vying for use of the same pins. I have not completely decided what is the best way to resolve the radio conflicts as those cards use a lot of pins. However I did press on and designed an interface card that handles all the other functions, so I don't need to struggle with card conflicts.

This custom expansion card handles:

  • 2 graphical LCDs
  • a 3-axis accelerometer
  • driver crcuitry for the gas tank exciter
  • signal conditioning for the gas tank sensor
  • a GPS
  • a couple of mode switches
  • and some power distribution

The card has significant protection on a lot of pins, partly because of all the potential pin conflicts and partly because the arduino uno connectors supported by the Nucleo MCU are expecting 3.3 volt signals on this platform, but the uno and many shields for the uno work off 5 volts, which is available on the connector.

Here is a picture of the PCB layout as it stands today:


I have all the parts on order I think, but some have long lead times, so this is going to compress the schedule down the road.

Hopefully I can now start installing the Nucleo IDE and begin exploring how to program it.


ITEAD makes it easy to follow the PCB build process on their web site - this shows the card is almost done...


Project Links:

IoT On Wheels Design Challenge page



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

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.



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.



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

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: