After fussing with two SPI devices that were not playing nice (namely, the TFT’s ST7735 and the NRF24L01+ radio), I turned my attention again to a graphic LCD module (MTB-368 from ETT Co. in Thailand) found on eBay back in January. Its M68-type parallel interface made it a bit trickier to get going. On top of this, it uses 5V logic, and my Teensy 3.0‘s Kenetis is 3V3. Google’s only hit for a datasheet was mostly in Thai. Thankfully, a quick email to the manufacturer yielded an English manual.
Next, finding a library that would allow me to talk to the GLCD with my MCU in at a high level. Thankfully, there were two candidates: openGLCD and u8glib. To correct for the logic voltage level mismatch, I used 10K Ohm resistors in series on the bidirectional data lines. After many hours of fiddling with code and configuration with both candidates, I was no farther along than illuminating the backlight and a few erratic lines through the display.
After posting to the Teensy forum at PJRC, I had contact with the developer behind openGLCD, Bill Perry, and with his help we were able to get the MTB-368 running. One point that was unclear from the GLCD module’s datasheet was whether the CLK pin (not common on SED1520-based controllers) was an input or output. After Bill correcting some timing and initialization sequences, the MTB-368 still wasn’t working, though it was behaving differently.
After looking for more MTB-368 modules online, I noticed the SBN1661 (a cousin to the SED1520) had a similar configuration with its backlight circuitry, and also required a clock. Based on a hunch, and after confirming there was no readable voltage on the pin, I configured my Teensy board to provide a 2kHz square wave (50% duty cycle) by adjusting Timer 1 (pins 3 and 4). With the LCD running on my new bi-voltage UNO, the Teensy was free to experiment with PWM timing. After a rough shot at the right frequency (I do not have a scope — yet), the MTB-368 leapt to life.
Having already done a experiment with a set of nRF240l+ PA/LNA v5.1 radios (recommended: conforms to layout spec), I hooked up the GPS on the client side (UNO) and the display on the server side. Both the Teensy and the UNO communicate with the NRF radio using the RH_NRF24 library and its ReliableDatagram manager. All my experiments to-date have used the library’s default rate of 2.402 GHz (channel 2), 2Mbps, and 0dBm. PA and LNA have not been used.
The biggest challenge in sending GPS data over the radio was getting the two fields, latitude and longitude, mashed together with the appropriate separator and passed in the correct format to the radio manager. According to RH_NRF24’s documentation, the data packet buffer requires an unsigned 8-bit pointer (uint8_t*). TinyGPS++ provides an object for every data field in a floating format. Thus my challenge was two-fold: mashing the two together and converting to a binary format needed for the radio manager.
This project quickly became a study in the differences of micro-controller C versus its big brother running on full computers. The usual suspects for type conversion, including stringstream and lexical_cast, are not included in the anemic version of C++ running under the hood of Arduino. Even heap functions, such as those used by printf in its floating number handling, is unavailable. After getting a grasp on data types, casting, and forming data to satisfy different applications (and compiling without error!), I discovered the hobbled printf wasn’t going to cut it. Fortunately, a quick Google search provided an alternative: dtostrf().
Some more fiddling with proper casting yielded a functional result. Data was received from the other side of the house with virtually no missed packets. Further work includes additional GPS fields, logging on the server, and display layout to maximize data on the screen and minimize refreshes. Experimenting with different channels, signal strength, and data rates. Additional sensors may also be included in the wireless mix.
Arduino sketch for the client: http://pastie.org/9381294