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:
- to read and parse the GPS radio
- 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:
Top Comments
-
mcb1
-
Cancel
-
Vote Up
+2
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
Comment-
mcb1
-
Cancel
-
Vote Up
+2
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
Children