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.

Why I hate writing UI code...

Now that the Atmel CPU is back alive, I have been back working on my beacon code.  The underlying beacon code is finished for the most part.  What I have been working on is the user interface (UI) code.  Why is it that UI code is so dang hard to write and debug?  I have decided that I suck at UI design, but I have taken a first stab at it.  As is typical in many of my UI projects, it quickly degenerated into an amazing snake pit of spaghetti code, especially for the code that takes care of changing the various settings on the device.

Take for example the seemingly simple problem of setting the realtime clock to WWV.  Set the clock values for the next minute and wait for the tone.

So, to set the clock, I put the device into clock set mode and display the current RTC information across the bottom line of the 4 line display.  I set the seconds value to zero and put the cursor on the hours value and start it blinking.  In the picture above, I snapped the photo when the hours value was blanked out.  Rotating the dial will change the hours value within the range of values allowed (0 - 23).  To move the the next value, a button push will cycle from Hours -> Min -> Day -> Month -> Year and back to Hours again.  Each value will start blinking once selected and changed with the dial.  Each setting value has a minimum and maximum value.  It can be an 8 bit, 16 bit or 32 bit value.  There is an option to pass in an array of text strings that are displayed rather than the numeric value as was done with the month value.

Once the value has been set, we wait for the top of the current minute and press another button to save the new value.  There is an option to abandon the set operation and return to normal operation.  The idea was to listen to WWV or some other time standard and set the clock at the top of the next minute.  I may allow setting the seconds value if I get tired of waiting.

So, this ends up being a big huge state machine.  It just seems like 80% of the code in this project is related to the UI.  On an embedded processor with limited code memory, this is something to keep track of.

So, I have ripped out all the spaghetti code and replaced it with my new "value setting" utility and now should be able to reuse it to do any settings for this project.  For example, space permitting I could provide a way to set the WSPR/QRSS beacon text by allowing each character to be set by the dial.  The code should now be easier to reuse and eliminate the exponential growth of UI code, at least for the settings utility.

New RTC and data logging shield for beacon project

I have built one of the fine data logging shields for Arduino from the fine folks at Adafruit to further clean up my beacon project rats nest.  The new setup looks like this attached to my Arduino Uno.

I need to add a socket for the DDS-60 and a couple headers to bring data GPIO lines out.  The real-time clock has been tested and is functional.  This should be my final setup until a PCB is created for this project.

WSPR Beacon update

Now that I have liberated GPIO pins for the RTC clock, I have incorporated it into my breadboard design.  I have the code to the point where it will begin transmitting on the next even minute.  I now need to implement the TX percent control, however I am uncertain what it means.  Obviously, TX percent set to 100% will transmit every 2 minute window and 0% will not transmit at all (Idle).  However, what does 50% mean?  Does it mean I will transmit every other 2 minute window?  Don't think so, but not sure...  I did see one online reference that 20% means transmitting every 10 minutes or so.  This came from the WSPR 2.0 user manual.  Here is that text:

WSPR uses two-minute time slots for transmitting and receiving. The slider labeled

Tx fraction sets the average proportion of time allocated for transmitting. The default setting of 20% is a good compromise under typical conditions: it means that you will transmit approximately once every ten minutes and receive the rest of the time. The exact T/R sequence will be randomized so as to maximize your chances of receiving other WSPR stations. For receive-only operation, set the Tx fraction slider to zero

My brain refuses to understand this for some reason...

I think what is intended here is the following:

transmit time = (1/transmit percent) * 2 min

If I round this up to the nearest integer, the following transmit times result:

100% - every 2 minutes
90% - every 4 minutes
80% - every 4 minutes
70% - every 4 minutes
60% - every 4 minutes
50% - every 4 minutes
40% - every 6 minutes
30% - every 8 minutes
20% - every 10 minutes
10% - every 20 minutes
0% - never transmit

I am not sure this is precisely what Joe Taylor intended, but I think it will be adaquate for the beacon project.  I will further randomize the precise amount of time between transmissions up to the calculated value to better match what Joe Taylor suggests for minimizing collisions between transmitting stations.

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.