Positioning Satellite Receiver module & NMEA Sentences

In my last post I mentioned a future project using a positioning satellite receiver module, ( GNSS receiver ).  Since then I've been trying out the MakerHawk GPS 51, incorporating the Goouuu Tech GT-U7 module*. It cost just GBP8.99 and includes an external antenna.

MakerHawk GPS 51 receiver with active antenna

For convenience ( least effort ) rather than a good view of the sky, ( which there certainly wasn't ), I positioned it close to my laptop ( in fact on top of the printer ) in the centre of a room far from two small windows, connected it to the laptop via a usb to uart serial converter, and opened a serial terminal program.

(L) Uart (R) MakerHawk GPS 51 in operation

I doubted if there would be enough satellites received in that position; but after just a few seconds "NMEA Sentences" were being streamed every second and a position fix given. I was absolutely amazed  !!

NMEA Sentences ( click on image to zoom in )

These text strings of comma separated values are known as "NMEA Sentences"; NMEA standing for National Marine Electronics Association. There is plenty of information online to explain the complete format in detail. For my project, I am particularly interested in the sentence starting $GPGGA. GP means it is the US GPS system, ( if GL here it would mean the Russian GLONASS system, GB Chinese BEIDOU, and there are others ), and GGA signifies that it is a position, time and fix data sentence. On examining this sentence I can quickly find the time, my latitude (N), and longtitude (E). The sentence also states, ( among other things ), that my altitude was 87.5m and that a total of 10 satellites had been acquired in order to give the position fix; not bad from the middle of the room.

Now I am going to write some software for my microcontroller to parse the $GPGGA sentence and display latitude, longtitude, altitude, and time, in a more user-friendly form on an OLED display.
* Advertised and sold online as being compatible with the UBlox Neo-6M receiver module. If so, then I assume that UBlox software ( eg u-centre ) and data-sheet for the Neo-6M at www.u-blox.com can be used with the Goouuu Tech GT-U7.
GNSS = Global Navigation Satellite System 

      

Digital Temperature Sensor with OLED Display

Temperature Sensor - MCU board & OLED display

Serial terminal window showing count & raw adc samples

I was working on this project in April but forgot to post it until now when I was thinking about a future project using this microcontroller unit ( MCU ) board and OLED display; but more about that later.
This digital "thermometer" uses the temperature sensor and 2 Analogue to Digital Converter ( ADC ) channels, integrated on the MCU board. I am using one ADC in averaging mode for temperature. Raw temperature data are sampled every 1.875s and the parsed result of the average of a count of 8 consecutive samples is displayed. Voltage is sampled by the second ADC in basic mode every 1.875s and displayed. This is not the voltage of the batteries shown in the image but actually the supply voltage to the MCU and OLED display. I also send the count number and raw ADC measurements using a serial interface to a pc running a terminal program.
The display shows what the device is, the version of the TEMPSENS-OLED firmware installed, temperature ( in degrees C & F ) with resolution 0.01 degrees, and "battery" voltage with resolution 0.001V. Of course I can change any of the above settings and parameters in my firmware.
In my recent projects I have only learnt the basics, ( such as displaying plain text ), of using an OLED display, and not attempted any scrolling, graphics or animation.
For the next project I am considering using the MCU and OLED display with a GPS receiver module. These are available on a well known online shopping site for as little as 4.26GBP including antenna. I shall also be buying a slightly larger 64 x 128px two colour OLED display to show altitude and position; the latter with possibly 1cm accuracy !
( Click on images to zoom in ).

More progress with the I2C OLED

OLED displaying real time data from MCU ADC

0.96" 32 x 128 pixel two colour OLED with I2C interface

I think the OLED is very cool. Since my last post I have been doing more with it than just turning it on or off. It quickly became obvious that mine has a 32x128px display area and not as advertised by the seller; however not really a limitation for my present purposes.
Having removed the Si5351 breakout board ( refer to previous post ) incorporating the I2C bus pull-up resistors on the SCL and SDA lines, I then had to provide these resistors separately ( 10K Ohm each ) for the OLED.
In my firmware, written in 'C' language, there is a look-up table of characters I created, with font based on a 8x8 pixel grid which gives exactly 16 characters per 128 pixel row. I have so far included only capital letters, 0 to 9, =, -, +, space and a few common punctuation marks; 41 in total.
It is essential to have the documentation for the Solomon Systech SSD1306 OLED driver. This was located and downloaded.
As in my post of 17 February 2019, the 10 bit analogue to digital converter ( ADC ) on my micro-controller unit ( MCU ) development board was used to sample the voltage on the slider of a potentiometer ( POT ) every 0.5s, and the result sent over I2C bus to be displayed on the OLED.
I now have the basics in place and ready to adapt to a future project which uses an OLED.
I would also like to try a white on black monochrome OLED which I might find easier to read.
( Note : OLED = Organic LED display ). 
     

Demonstrating I2C serial communications bus

Continuing the theme on serial interfaces from the last post, Inter Integrated Circuit, ( I2C ), is another type of serial communications interface, also called '2-wire bus', and is a very common peripheral interface. There is a master device, slave device(s), addressing and also a clock, making communication synchronous. Two connections are required; serial data ( SDA ) and serial clock ( SCL ).
In this post I demonstrate using I2C with a Silicon Labs Si5351 frequency synthesiser chip and a miniature 0.96" 128/64px two colour OLED display. Both have I2C interfaces but different addresses, hex60 and hex3C respectively, and so can be connected on the same bus. 

Master reads 1 byte from slave ( SCL = clock, SDA = data )

 The I2C protocol is more complex than that for RS232/485 in the previous post. The image above shows that a 4 byte transaction is required in order for the master to read in one byte of data from a slave, ( in this case Si5351 ). Compare to RS485 in the previous post.
The master is my usual micro-controller unit ( MCU ) development board which does have embedded I2C modules. I programmed it with my own firmware to enable and setup I2C to communicate with the Si5351 and OLED.

Top MCU, bottom L OLED, bottom R Si5351 board

Using I2C, I tested the OLED by turning the display on/off and switching between normal and reverse video. I configured the Si5351 on the purple coloured break-out board to generate two square-wave output signals, on my favourite frequency 137.7KHz in the 2190m amateur radio longwave band. See image immediately below.

Si5351 generates two separate output signals simultaneously

     

Adding a RS485 interface to an embedded control project

A serial connection to a pc can be used to send/receive data to/from a micro-controller unit ( MCU ) based project. Instead of using usb I have programmed a MCU's serial (E)USART ( (Enhanced) Universal Synchronous Asynchronous Receiver Transmitter ) peripheral and written my own pc software in the past for this purpose.
The USART has receive (RX), transmit (TX) and ground (GND) connections like the RS232 type serial COM ports on older pc's. For higher speeds or longer distances, however, RS485 is a better choice. [ note: RS = Recommended Standard ]. The MCUs and development boards which I use don't have RS485 interfaces. So I made one to test its capabilities. I used a 32MHz MCU clock. Therefore the maximum data rate possible ought to be 4Mbits/s ( 4Mbaud ).
As RS485 is a physical and electrical specification for the bus ( not a protocol ), the protocol used by the USART for RS485 can be the same "start-stop signalling"; i.e., one start bit ( always 0 ), 8 bits ( data byte ), one stop bit (always 1).

TX output from MCU USART. L-R: idle 1, start bit 0, 8 data bits, stop bit 1, idle 1

The image above shows, reading left-right, binary data bits 11001001, with the least significant bit ( LSB ) actually sent first from the left. Reversing the order to put the LSB in the normal position on the far right when writing the value down gives binary 10010011, which is also decimal 147. What really interested me was when I measured the duration of a data bit with the vertical cursor lines; 250nS, equivalent to a data rate of 4Mbaud.

MCU board with RS485 interface fitted - inset view from above

I made a RS485 interface on a daughter board which plugs into a MCU development board. As this uses 3.3V logic levels, ( 0 = 0V, 1 = 3.3V ), I chose the MAX3485ESA chip for the RS485 line transceiver. This chip has one receiver and one line driver; so works in half-duplex mode. Unlike RS232, the RS485 physical link is a twisted pair of wires. I already had 4.5 metres of this. The data signal I used was the voltage on the slider of a pot ( blue knob ), sampled by the MCU 10bit analogue-to-digital converter peripheral and sent to the USART. So. for example, the value 147 would equate to 474mV.

Terminal RX window showing data received from MCU at 2Mbit/s

This setup worked perfectly up to 2MBaud, as shown above, using my favourite terminal emulation software. Unfortunately the same virtual COM port could not be opened when I tried 4MBd ! In future experiments I will see if this limitation was due to the USB-RS485 converter ( not shown ) which I used to connect to a pc at the other end of the link.