Posted by: m1paf | January 27, 2009

Back in the programming saddle….

Just a quick update today.

I’ve been doing a bit more work on the comms and display code. The display now indicates if there is a comms error (timeout) by showing the word “ERROR” in place of the radio frequency (I thought the choice of word was original!) and if the frequency is outside of the memory range the limits change from displaying the upper and lower frequency for that particular memory location to “O.O.B.” (out of band). This is more intuitive than leaving the lower and upper frequencies displayed for the last valid memory location.

I’ve also done a little more work on the code that drives the display to make sure that all of the settings are displayed properly on power up, even if they are zero. The issue there was that I only updated the display when a value changed. That’s great, but a value that is zero is also zero on power up so it wasn’t getting displayed. Now I show everything on the display regardless of value the first time the display routine is called.

I’ve still got the code to write to handle master mode comms and to switch between master and slave mode but that’s not a big deal – I’ve had master mode comms working already but not in a way that allows switching between the two modes easily. The reason it’s straightforward is that the responses to the commands to read frequencies and modes are exactly the same as the messages sent by the radio in auto info mode.

73 Paul

Advertisements
Posted by: m1paf | January 26, 2009

EZNEC design file for Moxon

In response to a request for this (and I don’t know why I didn’t think to post it originally) I’ve put a link in the project related links section to a very simple web page I’ve created containing links to files I can’t put on the blog site. It’s not pretty but it is functional.

73 Paul.

Posted by: m1paf | January 24, 2009

Back to Barra

I’ve received an email from Steve, G0MTD, confirming our accommodation on Barra in the Outer Hebrides is booked for September 26th for 1 week. We are staying in the same place as we did in 2007 and it’s a fantastic spot.

Our accommodation on Barra

Our accommodation on Barra

There are other pictures on Steve’s website to give you an idea of what the place looks like. Sadly, Jim G7GAG who was with us on our last trip to Barra passed away very recently. If you ever get the chance to visit any of the islands I thoroughly recommend it whether it’s for radio purposes or not. I don’t know why but it’s a magical place.

73 Paul

Posted by: m1paf | January 24, 2009

Pointer problems solved

Hello friends – update on current state of play.

I have wired up the push-button switches to check the logic that stores and recalls the tuner settings and have had some fun debugging (remember fun is subjective – “learning opportunity” would be another way of describing it).

After a few hours head scratching I finally got the code working to save and restore the tuner values to / from the PIC EEPROM. This should be trivial as the compiler has built in functions to read or write byte data to the memory and I missed a key point from the example code provided that demonstrates how to manipulate variables that are more than 1 byte long.

The problem I was having was that I didn’t understand how C deals with pointers to variables and it’s a lot more sophisticated than I had assumed (there’s that word again – makes an ASS out of U and ME!) 

It’s a difficult concept for me to describe and my copy of Kernighan and Ritchie (see footnote) came to the rescue after I had read and understood the relevant sections. My mistake was to think that pointers in C are all byte aligned i.e. if you have a pointer to a 16 bit variable it points to the 1st byte and if you increment the pointer it points to the second byte – wrong diddly wrong wrong wrong. The pointers are intelligent – if you increment a pointer or add an offset it points to the next instance of the type of variable it is pointing to – not the next byte.

This was causing me problems because I need to store 16 bit numbers in the EEPROM, each 2 bytes long. My reasoning was thus:

  1. Obtain a pointer to the variable to be stored.
  2. Store the byte at the pointer address.
  3. Increment the pointer.
  4. Store the byte at the pointer address.

Reading the data back is basically the reverse of this process. The problem was that in step 1, I was getting a pointer to a 16 bit variable. Incrementing the pointer points to the next 16 bit variable not the next byte. To fix this I needed to “cast” (new techy programming speak for me there) the pointer to a byte type pointer. This means I get a pointer to the start of the 16 bit variable but when I increment it it points to the next byte.

I’m sure that I’m not the first person to come across this and I won’t be the last. The good news is that I now have a functioning controller that needs a little work to finish off the code. I’ve added an option to clear all of the tuner memories on power up by holding down two buttons and now need to add the code to switch between master and slave mode on the serial comms to the radio. This will also be a power up option retained in EEPROM.

73 Paul

Ref. The C Programming Language 2nd Edition, Brian W Kernighan & Dennis M Ritchie ISBN 0-13-110362-8

Posted by: m1paf | January 21, 2009

20m Vertical Moxon

Here you can find a draft document detailing how I built my 20m vertical Moxon antenna that we use on our trips to the Scottish Islands.

 

Vertical Moxon

Vertical Moxon

Link to Vertical Moxon PDF

 

73 Paul.

Posted by: m1paf | January 21, 2009

Musings on interrupts and encoders

I’ve been thinking about the code that handles the optical encoders and wondering if there is a better way to handle the interaction between the interrupt routine and the main code.

Currently each encoder has it’s own interrupt handler that is triggered by a rising edge on the A phase of the encoder outputs. The interrupt handler then looks at the state of the B phase to determine if the encoder is running clockwise or anti-clockwise and then increments or decrements the encoder value accordingly. There is a slight complication as the encoder value is stored as a 16 bit number that occupies 2 memory locations and the assembler that is generated by the compiler consists of a number of instructions to do a 16 bit add or a 16 bit subtraction.

Consider now what is going on in the main routine when I want to read the encoder value. Any read of the encoder value could be interrupted by the encoder interrupt handler between reading the first byte of the 16 bit number and the second byte of the 16 bit number. This would result in reading an incorrect value.

To avoid this problem I currently disable the encoder interrupt, read the value, and then re-enable the interrupt. This process is coded in a function that returns the encoder value and the interrupts are disabled for 2 clock cycles (100ns). For the logic to work correctly the interrupt must be handled within 1/4 of the encoder pulse cycle or the direction will be incorrectly interpreted. This gives a maximum pulse rate of 250k pulses/s. The encoders generate 128 pulses per rev giving a maximum of 1953 revs/s.

Now I know that the encoders will self destruct well before that (and I can’t turn them that fast!) so the code will work fine. The question on my mind is can I get the same effect in some way without having to disable the interrupts when I read the encoder value?

I guess the real reason for considering this is all about coding technique rather than whether my current method will work……….

 

73 Paul.

Posted by: m1paf | January 19, 2009

Development hardware pictures

 

The pictures below show the current development hardware (perhaps that’s being a bit generous – lash up)

Development hardware
Development hardware

 

 

What you can see here are the two stepper motors and their associated driver (the small green PCB at the back), the PIC development board (the small dark blue PCB buried under a rats nest of wires), the LCD display and encoders (mounted on the blue breadboard) and the PIC in circuit debugging interface (the clear box with the green LED). The two black cables coming from the PIC development board are RS232 cables – one goes to the radio and the other goes to a terminal emulator on the PC to display debugging messages in addition to the debugging information available via the debugging/programming interface.

The picture below shows a close up of the LCD display and how it appears to the user (in case anyone is interested the display is driven in 4 bit mode, requiring 7 I/O lines – 4 data and 3 control).

 

LCD display

LCD display

Apologies for the milky appearance of the photo, it’s caused by the protective film covering the display. Incedentally the display has a backlight feature that’s not connected yet.

On the first line you can see the frequency read from the radio (kHz only).

The second line shows the lower and upper frequency limits for this particular tuner memory. If the frequency goes below 7.180 the next lowest memory is selected and in this case (UK band limits apply) going above 7.200 will result in no change to the tuner settings.

The third line on the display shows the L and C settings (0 – 65535) and also provides indication if the motors are running by showing an asterisk (*) after the L or C value.

The fourth line shows the tuner mode (AUTO or MANUAL) , HI/LOW Z matching and HI/LOW capacitance settings.

The next step in the testing regime is to connect up the encoders and switches so I can prove the code that stores and recalls the L and C values from the built in EEPROM memory on the PIC.

 

73 Paul.

 

Update: The encoders are now connected and working so I can manually set L and C values – now need to check the code to save and restore to EEPROM.

Posted by: m1paf | January 19, 2009

Feb 2009 RadCom

For anyone who has (or who will) received their Feb 2009 RadCom, you absolutely must look at the wanted ad’s.

Enough said.

Posted by: m1paf | January 18, 2009

Similar projects from other amateurs

As a result of a recent trawl on the web I have found another design for a remote balanced tuner. It appears to go short of linking to the radio to automatically control the frequency related settings but it looks very neat. Not sure why I didn’t see this before but believe me I looked. Anyway, for reference the link has been added to the project related links and included here for quick reference.

K8AC – very nice project

73 Paul

Posted by: m1paf | January 17, 2009

Testing testing testing……..

Quick update on progress.

The first complete draft of the software is now ready for testing. I now need to get the soldering iron out and make up some cables for the lcd display, encoders, push buttons and home position switches. Hopefully I’ll have something to report later this weekend. I’ll also post some pictures of the lash up that is currently my hardware.

Cheers,

Paul.

« Newer Posts - Older Posts »

Categories