Thursday, 17 September 2020

Using E-Paper Display - Adafruit 200x200 BW

My son has a project that needs a display that must conserve power. E-Paper displays use NO power at all when not updating, and when the power is off they maintain their display! Incredible.

The problem with EPDs is that they need a buffer RAM on the microprocessor to store the entire display, in my case 200x200 pixels = 40,000 bit or ~8KB. The usual Arduino UNO or Nano only have 2KB. But the Adafruit display 1.54" 200x200 pixel Black and White display module has a additional 8KB SRAM built into the module to act as the buffer.

The graphic libraries (load using the Arduino IDE Library Manager):

Adafruit_GFX - graphic functions

Adafruit_EPD - display drivers

handle the use of the module 8KB SRAM automatically for you. Here's an example:

Connections are below

I have written a useful "header" file of functions for displaying text and numbers - it can and will be expanded I am sure to other function such as Date and Time. These are the current functions

Readme.txt

Adafruit 200x200 BW E-Paper Display. 

Include Adafruit_GFX and Adafruit_EPD libraries

Connections - uses SPI for display and 8kB SRAM.

SCK 13, MISO 12, MOSI 11

ECS 10, DC 9, SRCS 8

RST 5, BUSY 3

Constructor

Adafruit_SSD1608 epd(200, 200, DC, RST, ECS, SRCS, BUSY);

Colours, use prefdefined colours

EPD_WHITE 

EPD_BLACK

dispInit() // call in Setup() to initialise display

dispMsgS(uint8_t x, uint8_t y, uint16_t c, char *m) // display text

dispMsg(uint8_t x, uint8_t y, uint16_t c, char *m) // display text

dispMsgL(uint8_t x, uint8_t y, uint16_t c, char *m) // display text

dispNumS(uint8_t x, uint8_t y, uint16_t c, float n, uint16_t d) // display number

dispNum(uint8_t x, uint8_t y, uint16_t c, float n, uint16_t d) // display number

dispNumL(uint8_t x, uint8_t y, uint16_t c, float n, uint16_t d) // display number

dispUpdate()

dispClear() // clear display

dispDisplay() // display

x pixels across

y pixels down

c colour

m message

n number

d decimal places

As you can see this is the same approach I have used for small OLED (Oled.h) and colour TFT (Tft.h) displays. The file "Epda.h" is  here.

There is a demo/test file EPD_TEST for the display here that shows how to use it.


Monday, 14 September 2020

Web Site audio in Apple Safari

 I came across G4FPH's WebSDR site. It worked well, but there was no audio from the Apple Safari browser... I have met this issue before on other web sites.

G4FPH website

It seems that Safari controls audio for each web site you visit. To get it to work follow these steps

- Open Safari & the WebSDR site

- Chose Safari menu

- Chose Settings for this Website...

- in the small window that opens chose Auto-play and select Allow All Auto-Play

And presto, sound.

Sunday, 13 September 2020

Climate Emergency - seriously

Apart from my interest in Amateur Radio, I have another side (wow). A focus on what to do about the climate emergency. One of the major areas which I feel  we must address is transport - namely road transport. CO2 emissions from transport are going up, not down. In 2021 all makers must meet the level of 95g/km overall... or be fined HUGE amounts.

But some good news is the sales of BEV (Battery Electric vehicles).

 I have put on my download site (M0IFA.me) a collection of snippets "EV POLITICAL ..." about transport and electric vehicles, here.

And I invite you to read this report by The Institute for Government.

Friday, 4 September 2020

GPS clock, colour 2.4" TFT display

What a struggle! These TFT displays are awkward to use. Especially when you want to display a clock face and hands that move round, or for that matter to write text/numbers on the display and update them. To move a hand you must delete the previous line you have drawn and draw a new one. BUT, you cannot let the second hand, as it moves round, delete the minute or hour hand as it passes by...

Same for the time. When the hours, minutes or seconds change you have to write a black box over the original number and then the new time. Fortunately the simple Adafruit font does this by allowing you to define both the font colour and the background colour. The negative side of using the simple font is that it is very blocky and only small sizes can be used.

MY CLOCK

This is my display. Looking back at the choice I see the TFT is supposed to be 3.3V. But I am running it quite happily on the Arduino Mega at 5V... take care however, maybe it is better to chose an ILI9341 with 5V rating.

The display is complete after I added a calculation of
day of the week and the Maidenhead Locator.

The TFT has an ILI9341 controller chip. This is supported by the Adafruit_GFX.h library with the driver Adafruit_ILI9341.h. This graphic library is not very extensive, but does have to simple things I needed, filled rectangles, circles, horizontal and vertical lines, sloping lines, print of numbers and text.

The interesting code for the clock hands is this:

 - x, y = centre of hands

 - r = radius of clock

 - ch, h etc are the colours and hour, min, sec values

Typical usage may be

dispHands(110, 110, 100, WHITE, hrs, WHITE, mns, RED, sec);

This is the function:

// HANDS

// display hands x, y, r, ch, h, cm, m, cs, s

void dispHands(int16_t x, int16_t y, int16_t r, uint16_t ch, uint8_t h, uint16_t cm, uint8_t m,  uint16_t cs, uint8_t s) {

 uint16_t rh, rm, rs; // hand lengths

 static uint8_t xh, xm, xs; // prev hms data


  // hand lengths, % of radius

  rh = r * 60/100;

  rm = r * 80/100;

  rs = r * 90/100;


  // proportional move of hour hand

  h = h * 5 + m / 12.0; // 60 min / 12 hours, plus minutes / 12


  // if hms change erase old hand

  if (h != xh) {

  tft.drawLine(x, y, x + rh * sin((6.282 * xh / 60.0)), y - rh * cos((6.282 * xh /60.0)), BLACK);}

  if (m != xm) {

  tft.drawLine(x, y, x + rm * sin((6.282 * xm / 60.0)), y - rm * cos((6.282 * xm / 60.0)), BLACK);}

  if (s != xs) {

  tft.drawLine(x, y, x + rs * sin((6.282 * xs / 60.0)), y - rs * cos((6.282 * xs / 60.0)), BLACK);}


  // then draw current times

  tft.drawLine(x, y, x + rh * sin((6.282 * h / 60.0)), y - rh * cos((6.282 * h / 60.0)), ch);

  tft.drawLine(x, y, x + rm * sin((6.282 * m / 60.0)), y - rm * cos((6.282 * m / 60.0)), cm);

  tft.drawLine(x, y, x + rs * sin((6.282 * s / 60.0)), y - rs * cos((6.282 * s / 60.0)), cs);


  // remember current time

  xh = h;

  xm = m;

  xs = s;

}

Just to run though it

1. Three static variables for hour, minute & second are created in the function, these are remembered between calls. They store the "previous" values.
2. The length of the hands is set as 60, 80, 90% or the radius.
3. Hours are converted to 60ths and intermediate minutes added, so the hour hand slowly goes round with the minutes
4. A check is made to see if anything has been updated, if so the old hand is erased (written over in BLACK colour)
5. The new hands are written. All of them MUST be written as an erase of the secondhand as it passes over the minute of hour hand will "black" it out!
6. Finally the current values are stored for the next call.

All the date & time and display functions have been written in a "Tft.h" header file, here. And the sketch code TFT_ADA.ino is here. Name started off as "TFT using Adafruit" library, but it stuck.

TIME
So where does the time come from? GPS of course, and this is relatively easy to do using a GPS module and the TinyGPS library. See the sketch for the code.

Here it is running on an Arduino Mega
Display: CLK 13, MOSI 11, RES 8, DC 9, [CS 10, MISO 12 not used]
GPS: RX 18, TX 19

UNO or NANO
It should work equally well on an UNO or NANO but you will have to change the Serial code to use the SoftwareSerial.h library to create a new Serial TXRX port on a couple of pns - I suggest A0 & A1. I use the Arduino MEGA every time I need more than one Serial port, as it has the normal USB/Serial port plus three others (1, 2, & 3) that can be used. It has a bunch more memory too if you need it. This sketch doesn't.

QSO

The project has obvious use in the Amateur Radio shack for logging QSOs and checking the timing of transmissions - including for example FT8 which must start +/- 1 sec from the 15 seconds boundaries.


Wednesday, 2 September 2020

More on Digital SSB generation

 If you look back through this blog you will see (June 2020) a couple of reports of me delving into generating SSB signals using the digital "Phasing Method" using a Teensy processor to do the DSP processing using a couple of Hilbert filters. Hilberts give a band pass characteristic, plus they can be programmed to provide a signal phase shift. The design uses a +45 and -45 deg phase shift to generate I & Q audio signals, which are them fed to a couple of balanced mixers with RF I & Q signals. The result is USB or LSB SSB signals.

The SSB generator. Left Si5351 RF I & Q signals
Centre mixers and audio amp
Right the Teensy processor and mic input

It worked but it had a problem with the Hilbert filters, as they were limited to 70 to 100 taps, the Teensy could not handle a longer filter. This in turn caused the phase shift to move away from 45 deg at low AF frequencies. This then generated opposite sideband break though.

To tackle this I have added a couple of further processing steps. The Teensy processor is mounted on an audio ADC/DAC board and this can provide some audio preprocessing by itself. I have programmed it to provide an EQ with a passband of 500Hz to 3kHz and also an auto volume control, or compressor function. This is the code snippet

  soundcard.audioPreProcessorEnable(); // preprocess -3dB 500-3000kHz

  soundcard.eqBands(1.0, -1.0);

  soundcard.autoVolumeEnable();

  soundcard.autoVolumeControl(0, 1, 1, -10, 0.1, 0.1);

The full code for the app is on my website M0IFA.me here, it is called TEENSY_TX_ABPF.

On a listening test I found a significant improvement in the SSB punch and a reduction on the other sideband and correct side band audio BW.


Sunday, 30 August 2020

GPS QSO aid, Position & Time and Clock

I have been busy. It has always seemed to me that a GPS could be useful in the shack and in the field, So I have developed a very simple piece of hardware and a sketch to give 3 views of GPS data.

A GPS receiver can give you, amongst other things, the date, the time and your position in latitude and longitude. These things can be useful to the radio amateur, date and time for logging QSOs, and lat & lon translated to Maidenhead Locator for your stations position. 

I have chosen to display 3 different views, like this

The first is a display for QSO use, the second the raw GPS data and the third a conventional clock. All times are in UTC as this is GPS basic time.

BLOCK DIAGRAM / CONNECTIONS

After this digram was drawn I added a three way toggle switch connected to UNO pins A2 - GND - A3. This selects the type of display to show on the OLED display.

SOFTWARE
The software needed for this project is on my web site M0IFA.me.

1. The sketch itself is called GPS_HAM, copy and paste it into a new Arduino sketch and save with this name.
2. An Oled header file which gives the initialisation and  a set of functions based on the public u8g2 library for displaying text, numbers, clock hands, dates and times (and lots more if you need them). Put this is a folder called Oled in your libraries folder
3. The u8g2 library, which you can download from the internet, or copy from my site libraries
4. The Arduino SoftwareSerial and TinyGPS libraries which, again, you can download from my libraries.

Put Oled, SoftwareSerial and TinyGPS in their own folders in your local "libraries" folder.

BOX IT
I have ordered a small plastic box in which I will mount an Arduino Nano (replacing the development UNO I used), the GPS antenna and NEO-7 module and the OLED display. It will be powered from a 12V supply to the Nano which will them power the OLED and GPS.


Saturday, 22 August 2020

Time to tidy up our SSB transmissions

I have been astounded at the quality of SSB transmissions that are revealed by today's SDR receivers which show both a waterfall and a band spectrum. These are as seen on Hack Green SDR WEB receiver.

When I focused in on different transmissions I find

1. GOOD MODULATION

Beautiful, clear, full audio bandwidth, excellent audio processing.

2.  VERY BAD SPLATTER, PROBABLY DUE TO OVER MODULATION

Very poor and over modulated transmissions two on both sides and one on one side only. These transmissions often received reports of "good audio" which just shows that the quality of SSB transmission cannot be judged by just listening.

And it can't get worse than this

Just as he said "thanks for the report on good audio". Report "no audio artifacts", needs to use an SDR.

3. BOGGLED TRANSMISSIONS


This is about the worst in terms of quality. Patchy audio EQ, severely bass heavy and muffled and an outstanding transmission of a faulty transmitter or a wrongly used audio processor, giving a transmission of more than 9kHz wide!! This gentleman received a report of "clear, good audio"!!!

Then check this out. Two guys talking about "I like to focus on audio..." Here's the same guy again at 9kHz wide and severley distorted at the top end.


SDR BW is 3kHz, so top one is 4-5kHz wide and the bottom one more than 9kHz!!!

AND ACROSS 80M 


Very mixed quality of signals. Lot of audio processing and poor/good microphones?

NEW CODES NEEDED

The regular reports of 5 and 9 are not good enough. We need a better reporting system - a bit like SSTV which reports 5 & 9 plus video quality.