M0KHZ’s Blog

This blog update shares some recent learning and introduces yet another form of technology (new to me). Over the last couple of weeks I’ve been helping a good friend climb the steep learning curve of C programming for the PIC environment. As an exercise we have been playing about with a number of different sensors and are well on the way to developing a useful shack weather station. At present all of these sensors are wired back to the PIC hardware. This work has lead me to start formulating another strategy, wireless.

As an aside to this development, I have started to pull together a shopping list for my remote antenna tuner - PIC-a-Tune designed by Peter Rhodes G3XJP. This unit will when built sit outside at the bottom of my mast in a weather proof box. This project will be a significant investment in both time and money and it would be a really good idea to have some form of environmental monitoring inside the case, the main problem being moisture. Peter has very cleverly avoided the need to feed this ATU with any control wires, and the only connection between the shack and the ATU is the coax. A wireless humidity sensor sending data back to an interface in the shack would be a very good idea, so I’ve been Goggling different wireless solutions and have stumbled upon CyFi from Crypress.

The implementation of this technology is a drag and drop function block within the PSoC development IDE. OK so what is PSoC? What follows is a very brief summary:

Programmable System on Chip - PsoC, nothing new here, however this technology allows both analog and digital building block, together with an 8-bit MCU on a single chip, replacing multiple discrete components.

It’s the wireless building block that most interests me:

‘Cypress’s CyFi^TM Low-Power RF is a reliable, simple and power-efficient wireless sense and control PSOC technology that operates in the unlicensed 2.4 GHz ISM band. The solution is made up of a PSOC device, CyFi Transceiver and a CyFi Network Protocol Stack. This solution combines ultimate reliability with Direct Sequence Spread Spectrum (DSSS) technology and 80 channels for flexibility; implementation simplicity with a drag-and-drop network protocol user module, and best-in-class power-efficiency.’

Cypress can supply a PSoC FirstTouch wireless starter kit, providing a number of different sensors to start experimenting with:

7 element capacitance sensor slider
Capacitance proximity sensor
Thermister
Ambient light sensor
Red or green or blue triple LED cluster
Speaker

Plus of coarse an RF card with an RF output of upto +20 dBm.

Within the kit there is a wireless USB dongle that also doubles as a programmer. I will be ordering one of these kits shortly and am keen to start experimenting There is possibly an additional spin off to this, other than learning something about this technology, as there is another PSoC building block that implements touch screen capability. With this I can overlay the touch sensor on my graphical LCD display, and eliminate the hardware buttons on my developing transceiver controller - probably just a dream, but you never know

End of update.

This short blog update shares a weekends fault finding here in the shack. I stripped down my HPSDR hardware, resulting with my two Atlas back planes on the bench side by side. Visually there was no discernable difference, this followed by resistive measurements of each line, once again no difference. I then (out of frustration) tried the Pico-120 module again, and the module WORKED on each card! I then populated Atlas with Ozy, Penelope and Mercury and tried again, success, everything was working. Frustrated by not finding a fault, I re-built my HPSDR hardware, powered the chassis on, and the Pico-120 went into shutdown again!

OK I was getting really confused and frustrated by now, what was the difference, other than a physical desk change? The 12V PSU I was driving the Pico. Checking both my construction bench supply and my main shack PSU showed there was no difference in supply voltage, 13.8V, the only difference was the ‘type’ of regulation being deployed. My main shack supply is via a switch mode power supply, alarm bells started to ring and I dragged out the scope to look for some sort of high frequency component on the supply, nothing found!

Once again out of frustration, I swapped out the switch mode supply for a standard analogue PSU, yep you’ve guessed, the Pico module worked!

Although I can’t see anything on my 50Mhz scope, I’m assuming there is some high frequency component on the supply line from the switch mode PSU, and this is causing the shutdown system on the Pico-120 module to shut down.

Suffice to say I’m now using the analogue PSU as my main shack supply, and the switch mode unit is being used only for accessories on the bench

End of update.

This is a quick blog update sharing an issue I discovered last night. If you have been following recently you will be aware that I am very close to getting my HPSDR build ‘on-air’, and for those who are not aware of the hardware infrastructure, depending on your specific requirements, you plug in the appropriate cards into a backplane (named Atlas), in a similar fashion to plugging in cards into you PC motherboard.

OK Atlas is designed to be powered by an ATX type PSU, and I have 2 Atlas boards here in the shack, one used for development, the other mounted in the case for my transceiver build. The issue I have is, either Atlas boards work fine with any ATX PSU I plug into them - fine this is what I expect, however I also have a small Pico-120W ATX PSU, this unit is only working on 1 of the Atlas back planes? To make things awkward the working board is my test board and NOT the one mounted in the case!

So I’ve an interesting issue to resolve, before further progress can be made, the first stage in the fault finding will be to strip out the non working (with the Pico-120 module) Atlas board and have both boards side by side on the bench to enable some comparison test to be made. This sounds straight forward, but it does require a full hardware strip down of the case, doable but time consuming.

End of update

This is a quick blog update, sharing the news that I’ve finally wired up the building blocks for my HPSDR transceiver project. Below is a short video detailing the build so far, the final        steps to make good are the LPF switching - currently hardwired for 80M and improved Tx/Rx relay as the current one is rather LOUD with operating!

Oh yes I almost forgot, the music for the video is homebrew also - I’ve been playing with some new software, hope you enjoy a rift of 12 bar Blues

End of update.

This is a short blog update sharing recent progress on the UI. Instead of attempting to sort out the button, I’ve looked at the S meter bar graph. My initial method was to clear the entire bar graph area by writing to each pixel, and then write the current value to the screen. This KILLED the screen update frequency and caused extreme delays when changing frequency. My second method was to write the value to display and only clearing pixel that were not required. This seemed to work very well. Today I’ve added a ‘growing / thickening’  bar as the signal strength increases. I’m not sure I like this but will leave it ‘growing’ for a while. Finally just to test the display I’ve added a couple of counters running via interrupts to sudo randomly change the signal strength.

Here is what it current looks like:

I guess the next step will be to return to the buttons, but probably not this weekend as I’ve some other tasks in the shack that require attention.

End of update

This is a very quick blog update, sharing some further understanding regarding the address mapping of the graphic display I’m using here.
The LCD glass matrix is controlled by a Toshiba T6963C chip. This chip will support up to 64 Kbytes of external RAM. This external RAM is allocated areas for text, graphics and external character generation. Depending on the manufacture of the graphic module, different amounts of external RAM is provided. Unfortunately today, I have discovered my inexpensive graphic module from eBay only has 4 Kbytes of RAM installed.
Once allocation has been made to support text and graphics, for the 128 x 64 bit display area, there is only 128 bytes left for CG RAM. Unfortunately and quite by chance I’m already using 100% of this area for the S Meter graphic! This is why I’ve been struggling to understand, and make work additional bitmaps for buttons. You start to get some really weird results:

I’m not kicking myself too hard though, as armed with my recently gained knowledge, and checking the data sheets for the ‘expensive’ display from a well known UK supplier, I was intending to purchase, I have discovered this display has EXACTLY the same restrictions!
OK so what does this mean? Well I guess I could either write the S meter manually bit-by-bit, freeing up room within the CG RAM area of RAM, or keep the S meter bitmap where it is and manually create each button. I believe I will very quickly runout of space in CG RAM for buttons, as there is only really enough room for 4 or 5 ‘readable’ buttons. So I guess I don’t really have much choice, so I’m going to embark on attempting to write the buttons ‘bit-by-bit’. Time for some more learning, bit bashing on a grand scale!

End of update.

This is a very quick blog update, sharing progress to date. I now have an interrupt driven encoder fully functional, together with the start of the main interface screen, see below:

The next step in the dance is to understand how to place some button bitmaps along the bottom of the screen. These will be dynamic depending upon where I am within the menu structure. I’m hoping to devise something straight forward with just 4 buttons, only time will tell.

I am reasonably happy with progress using this display, I have gain a large amount of knowledge while getting this far, my only real wish is the lack of pixels to play with, 128 x 64 pixels isn’t enough, but for now it will have to do

End of update

This quick blog update, sharing some learning here in the shack, and I’m sure any programmers reading this will have a giggle from todays experience

OK where to start…. if you have been following this blog over the last few days, you will have seen slow progress on the C code for the PIC. I’m starting to develop the user interface (UI) for my new transceiver, anyway while pulling this together I need to use a particular function, this function writes a string to the display in graphics mode.

Still reading? So this works just fine:

char default_display_text [ ] = “Loading data to eeprom”;

strcpy(text_buffer,default_display_text);
GDispPixFontAt(23, 1, text_buffer, 1, BLACK);

However, the string I want to display, needed some formatting prior to displaying, to cut a very long story short, and many hours trying different coding techniques, the penny finally dropped, with the fact that, for the function GDispPixFontAt to work, the string needs to be terminated with a NULL ! Bloody obvious really, and was a simple fix, here is a snippet of the actual code :

// convert vfo frequency to string
int32_to_string(curr_disp_freq[0], freq_string)

if (freq_string[3] == ‘0′)
disp_buffer[0] = ‘ ‘;
else
disp_buffer[0] = freq_string[3];

// Load disp_buffer with most significant 8 ascii characters
for (j=1; j<9; j++) disp_buffer[j] = freq_string[j+3];

// I had a lot of issues here, eventually the penny dropped
// and I placed a NULL at the end of the disp_buffer string
// now when I call GDispPixFontAt(); I get the display
// I am expecting! - I’ll try to remember this leason

disp_buffer[9] = 0×00;
GDispPixFontAt(8,12, disp_buffer, 2, BLACK);

This stupid error has cost me the best part of the day, fault finding! Learn my mistake, terminate strings with a NULL!

The coders reading this, feel free to giggle

End of update

This quick blog update, shares some great news that Paul M0CJX is re-releasing PCB’s for Peter Rhodes excellent PIC-a-Tune project. This is a fantastic opportunity to homebrew a high class, fully functional Auto - ATU with 200W transmit capability.

Further details can be found here at Pauls web site:

http://www.picatune2.co.uk/

At a cost of £25 for a set of boards you will NOT be disappointed.

Copies of the original articles can be found at Peters Yahoo archive site, found here:

http://uk.groups.yahoo.com/group/picaproject/

Happy homebrewing!

End of update

This is a quick blog update sharing progress here in the shack. After struggling for hours, I’ve finally worked out how to create, format the data, store in the glcd CG Rom and display on the screen

I can now at will generate my own graphics for display, so the fun can really start now on developing my own controller for my next transceiver. I must admit this has been a steep learning curve!

Creating the bitmaps is no deal, I’ve discussed this in the past. The controller for my display, a T6963C manipulates bytes from left to right - LSB first. Creating a data table for this structure once again is straight forward and there a number of free software applications that will do this for you. I’ve been using ‘bitmap2LCD’. The tables created have been used to populate the data arrays within the software. All straight forward? NO!

To display a bitmap, I’ve been storing the data table in the Character Generation ROM of the glcd, once loaded, I’ve then displayed the stored characters - apparently it’s easier and quicker this way? Anyway, every time I tried I failed, more gobbledygook on the display!

Consulting the driver manual, I eventually discovered that the CG Rom area needed to be feed most significant bits first - MSB 1st! OK I now understood what I was doing wrong, I searched high and low for an application that would convert my previously generated tables into the correct format - 8×8 for CG ROM storage, but failed miserably.

Finally I settled on manually formatting the data tables into the required data stream. A real pain in the butt, but at least I can now move forward.

End of update.