Minima Displays

I have been playing around with a number of display options for the Minima.  I found an interesting little board locally for about $12 in single quantities and on eBay for about $5 that has 8 digits of seven segment display, eight tri-colour LEDs and eight push buttons.  It is based on the Titan Micro LED driver chip TM1638.  Here is a good write-up on the device, I won't attempt to replicate it here.

I very quickly modified the Minima code to utilize this display.  It could very easily be further adapted to support the various buttons.  Some of the LCD second line indicators (RX/TX, LSB/USB, etc) could be indicated using tri-colour LEDs.  

I thought folks might be interested in seeing this device and I wanted to get a feel for how difficult it would be to integrate into the Minima code.  Out-of-box, it requires three of the scarce pins on the Arduino, but this can be easily resolved by expanding the I/O pins using a i2c device very similar to what is done with LCD backpacks for i2c.

Here is a photograph of my UNO running Minima version ko7m-AD with modifications for displaying the frequency.  My Minima controller shield is in place but not currently powered.

Anyone interested in further details on this display board should see the links above.  if you have trouble integrating this into your Minima code, drop me a note by email or by comment here and I will do my best to help you succeed.

ko7m at arrl dot net

Minima Controller - 5V i2c LCD support

I have tested my Minima controller successfully for support of 16x2 or 20x4 LCD displays using a 5V i2c backpack.  Here is a 20x4 display running my changes to WA0UWH's latest firmware for Minima.

Only two wires plus power and ground required to support these displays.  The code is conditionally compiled with or without i2c display support as desired with the default to continue to support 6 wire displays.  Converting to an i2c display will be required in order to free up I/O pins to support such things as rotary controllers, keyer paddles, etc.  This change however will continue to work by default with the original Minima hardware configuration for the LCD display.  In order to enable the functionality, please uncomment the following line near the top of the file "radiono.ino".

    #define USE_I2C_LCD 1

  You will also need to obtain the i2c library LiquidTWI and install in your Arduino environment in order to build with this support.

It should be noted that my Minima Controller shield is not required to support i2c displays.

Please contact me directly by email at ko7m at arrl.net or by commenting on this post if you have any problems and I will do my best to assist.

New LCD display

I have just received a couple of nice little display modules from China.  These cute little devices are I2C interfaced and use the MicroLCD Arduino library for the SSD1306 controller.  http://freematics.com/store
 
The displays are relatively cheap in single unit quantities of USD9.95.  Two of them and 90g shipping delivered for USD24.85.  Shipping took 12 days.

The device is a 3.3 volt device and interfaces nicely with the Arduino if you remember that you don't want to use the internal pull-up resistors and instead use external resistors to a 3.3 volt rail.

The display comes in two relatively small formats 0.9" and 1.3".  Since it is an OLED display, the direct sunshine readability is excellent.

Since I have converted my Minima code to use I2C displays, I decided to hook it up and modify the Minima code as necessary to utilize this display.  The result is as you can see below.

As is the case with most things I buy from China, there are a couple of anomalies that I have noted...

1. The first two pixel columns are not visible on the display.  By offsetting two pixels to the right, the result is what you see above.

2. There is no cursor support in the shipped library (MicroLCD) so some investigation will be necessary to see how to implement similar functionality.

This should be fun for a number of projects, nice and compact and easy to interface, anomalies and all... 

Here I have increased the font size for my tired eyes.  I think it still looks pretty good.

Rotary Encoders on Propeller

This evening, I have been playing with Eldon's code to handle rotary encoders.  Works nicely as long as the encoder inputs to the propeller have pull-up resistors and a capacitor to ground to make a little integrator.  Helps with debouncing the encoder output.

So far the LCD driver is working nicely for both I2C displays and parallel displays.  Eldon seems to have switched over to using mine.

I will next work up some code to use the encoder for frequency selection.  Everyone else is well beyond this point, but I have focused mostly on the WSPR encoder solution whilst everyone has been continuing on with UI and other concerns.  I will catch up here soon...

Propeller LCD and RTC work (cont.)

In a previous post, I mentioned that I was working on an I2C LCD driver.  I have decided to support both I2C and parallel interfaces to common LCD displays that utilize the popular Hitachi HD44780 controller chip.

This work is largely completed at this point although there is some clean-up work to be done.  One of the dilemmas I face is the question of how to implement cursor positioning.  It is simple enough to envision an API that sets the cursor to some row/column pair, but should those rows and columns be zero-based or one-based values?

I have worked forever on systems wherein all such values are zero based.  There does appear to be however some precident for using one-based values.  For the moment, I have implemented two APIs, one that is zero-based and the other one-based.  Perhaps that is an acceptable, albeit confusing solution.

I welcome any thoughts anyone might have on the topic.

Propeller LCD and RTC work

Sorry for no updates for a while as I have been ill unfortunately.  Starting to feel better now however so I am back playing around with propeller.  I have a DS1307 real-time clock module (RTC) and the I2C LCD module from my Arduino beacon project that I have been wanting to get working.

The RTC was a complete no-brainer, it just works.  I plan to use it to allow atonomous operation of my beacons that need accurate time information such as WSPR.

The LCD however was a bit of a problem as I am not happy with the display drivers that are out there and have not found an acceptable I2C implementation for any display that I care for.

So, I ported the driver I was using for Arduino to spin and have it working now at least at a macro level.  I have not tested the functionality fully yet.  I am quite pleased with the initial performance.

The plan is to make a rather comprehensive driver that will work with either I2C or parallel mode, though I only will be using I2C.  Above you can see it driving my 20 character by 4 line display.  The I2C bit is implemented in the driver via bit-banging.  This allows the driver to be independent of any other I2C library.  The SDA and SCL pins can be specified with the default to share the I2C pins with the EEPROM.

On other fronts I am putting together a low pass filter module that uses six relay selectable low pass filters for the HF Bands 160 - 10 metres.  10 bands are covered with 6 filters.  Attenuation in the stop band should exceed -40dB.  I anticipate using an 8 bit I2C I/O expander, six bits of which will be used select the appropriate filter for the following bands: 160, 80, 60/40, 30/20, 17/15, 12/10 metres.  I anticipate using the remaining bits for transmit/receive switching and antenna auto-tuner control.  More to come on this.

New Propeller Toys

I have obtained a touch panel LCD display for my Propeller board.  I am using a modification of the TV object to display text output for debugging purposes.  It is nice to have this peripheral display to make debugging easier.  Here is some debug output from my work on a routine to encode WSPR messages:

Nice little display.  It is a 320x240, 2.4" Colour LCD with touch screen.  It mounts to a prototyping board and leaves 15 IO available when connected in 8 bit mode.  It can display true-colour, 24 bit images and has a controllable backlight.  It also sports a full size SD card slot that can be used for offline storage.  Here is an example of the graphics display.

I think this will prove to be quite useful in my projects.

LCD Performance and UI decisions in the beacon project

The beacon project is back on the front burner.  Frankly, one of the reasons that it has been stalled so long is because of the lousy UI performance.  The rotary encoder triggers an interrupt so I never lose control turns.  However, the display updates are very laggy and the amount of lag varies considerably.  I *HATE* laggy UIs and until now have not looked into why.  Frankly the I2C LiquidCrystal library was apparently a hasty adaptation of the original LCD library without regard to performance.  It was taking more than a dozen I2C commands for a single character to be updated, let alone the additional ones for cursor positioning and the like.  Bogus.  All bits are written simultaneously now and the lagginess is completely gone.  Sweet!  Many thanks to Kevin who pointed out the great work by falconfour in a comment to one of my previous posts.  Nice to be back on track and re-energized to complete this project.

I spent a lot of time talking to my pal Eldon about UI decisions.  I will be making some changes to the value setting library for alpha-numeric fields to see if the new paradigm works a little cleaner for non-numeric fields.

Another concept that we kicked around was the effect of TX percent on multi-band operation for WSPR.  Since WSPR frequencies have been cleanly defined for all bands, I am considering having TX percent of 100% mean the beacon will cycle through all bands on each two minute window.  A setup UI would be created to allow enable/disable of each of the bands.  See my previous post for a list of bands supported by this beacon (all up to and including 6 metres).  So, if you truely wanted to send 100% of the time on one band, you would have to disable all other bands as well as setting TX percent to 100%.  Otherwise, the beacon would sequence through the list of enabled bands every two minute window.  I am interested in feedback on this idea.  I think it makes sense to enable this multi-band mode only on TX percent = 100% as otherwise, i would have to completely rethink the meaning of TX percent when multiple bands are enabled.

Also regarding multi-band operation, I plan to make some concession for external low-pass filter selection based on the currently selected band or frequency.  Interested in feedback on what this might look like.  Some ideas:

1. Provide the frequency to an external function that takes care of the magic itself and leave the details up to the implementer.
2. Provide an enable bit (or a counter that is decoded by external hardware) that can be used trigger external relays to select an appropriate low pass filter which is set by one of the following:
• The function described in #1 above as implemented by someone else.
• Providing a set of configurable cutoff frequencies for the various external low-pass filters and automatically selecting one as appropriate based on frequency.
• Define one filter per WSPR band and select based on frequency.  This is simple, but may be somewhat inappropriate as for example it makes little sense to have separate low pass filters for both 12 and 10 metres where one would suffice.

I have decided to replace my current rotary encoder with a different one from BI Technologies.  The Model EN11 rotary encoder is a nice, inexpensive (even in single unit quantities from Mouser) item that adds a push button and detents.  My current encoder had no detents and frankly, I prefer having them.  If desired, it can be ordered with or without the switch or the detents.  I will be using the switch to change the tuning rate rather than a separate push button.  See the datasheet here.  Thanks to Eldon for providing a sample of this encoder to me to try out with the beacon project.

Eldon and I also revisited the whole topic of what frequency to display on the LCD when in WSPR mode.  Most folks that use the great software by Joe Taylor are used to setting the rig display (on 30 metres for example) to 10.138700 MHz and generating tones in the 1400-1600 hz range to feed into your SSB transmitter.  The actual transmit frequency can be set by double clicking in the "waterfall" display or by typing it in to the "Tx:" frequency edit box.  One idea kicked around was to only display the WSPR band (30 metres, 20 metres, etc) and an offset from the start of the WSPR band.  The offset is only 200 hertz total.  This sort of makes sense to me, but I have an uneasyness when I don't know precisely what frequency I am transmitting on.  Joe Taylor's software shows the exact transmit frequency.  For example, if you clicked in the middle of the 30 metre band, it will show 14.140200 in the "Tx:" frequency box.  What is not clear to me is precisely what that frequency means since WSPR signals are composed of four separate tone frequencies that are separated by 1.4648 Hz.  In the absence of clarity from Joe's documentation, I have chosen to define the transmit frequency like this:

Each symbol is 1.4648 Hz apart and the displayed transmit frequency is mid-way between symbols 1 and 2.  Band edge operations need to take this into account if you wish to stay within the defined WSPR frequency range with the entire 6 Hz spectrum occupied by the complete WSPR signal.  Anyone have further thoughts or comments on this?

Anyway, it is nice to be back on track and making progress on my beacon again.

I2C LCD performance

I am a bit disappointed in the performance of the Arduino LCD driver, especially with the I2C interface enabled.  I am not sure how much time I want to spend optimizing the standard Arduino libraries, especially since a beacon in operation really doesn't need a display.  Realistically, it is just convenient for me while developing this project.  I think what I will do is just optimize the display usage to only update what actually changes rather than repainting everything whenever anything changes.  If that is insufficient, I will turn off the frequently updated portions of the LCD when doing time critical operations such as when transmitting signals with critical timing criteria such as WSPR.

GPIO Liberation

I have been endeavoring to liberate I/O pins on my Arduino project.  To that end, I have moved to an I2C LCD interface.  This is necessary to enable integration of an RTC (real-time clock) for WSPR timing.  The new setup looks like this:

I have some concerns about the performance of the LCD driver so I may have to do some customization of the driver.  The good news is that the beacon in operation is unlikely to have or need a display or rotary encoder as the set of operational frequencies will be fixed.  Calibration of the DDS-60 can be accomplished with a test setup that includes a rotary encoder to set the clock and then disconnected for day-to-day operation.

So, hopefully I can get the RTC integration done soon and have a fully functional WSPR/QRSS beacon breadboard completed.

Many thanks to the good folks at Adafruit for the excellent work on the I2C LCD interface.