Two more functions have been tested:
- up/down scan (mimics microphone up/dn buttons), with stop too
- "quick tune" for automatic antenna tuners
The up/down scan allows you to scan through the band at the normal scan speed. Takes two buttons, and a third if you also want a "stop" control. Otherwise scanning can be halted with a quick PTT press, or a touch on the morse key.
The "quick tune" sets the mode in FM and keys the PTT for 5 seconds (need more? need less? no problem!), then returns to receive in the original mode. With this function you must take care of the output power level and antenna choice (front/rear) in order to preserve your RF finals' health. No more no less how you'd do it by hand. This function can be assigned to a key or, for safety reasons, to a submenu (ie. within presets or mode combinations).
These two functions can be loaded on customized firmware and replace other functions: you still have got 16 keys and 2k limit on the program!
20 November 2008
17 November 2008
FT817 keypad - the homepage is out
Finally, the keypad has a homepage.
User's Manual and schematic diagram have been published, as well as a side-by-side comparison of similar FT-817 accessories.
The firmware is available on request (see the User's Manual for details).
User's Manual and schematic diagram have been published, as well as a side-by-side comparison of similar FT-817 accessories.
The firmware is available on request (see the User's Manual for details).
15 November 2008
Keypad - Saturday afternoon fever
For a few days I did not look at the keypad code. Then I realised I could do one more optimization and... Now it fits all 16 QRP presets with mode, mode change, VFO toggle, VOX toggle, power level and meter mode. And direct frequency dial, of course.
Now it does not miss a thing!
Now it does not miss a thing!
12 November 2008
FT817 keypad - how it looks
After a lot of monologue about the keypad, here it is! As you can see, it is real.
On the left of the picture you see the simple parallel port programmer. The keypad pictured is not connected to the radio or power supply.
I might shoot a video of the keypad at work...
On the left of the picture you see the simple parallel port programmer. The keypad pictured is not connected to the radio or power supply.
I might shoot a video of the keypad at work...
07 November 2008
FT817 Keypad: good and bad news
Hooray!
The GOOD news: I have been able to control power level, meter mode and vox.
The bad news: as expected, all functions don't fit. So mode change had to be dropped (but it has dedicated buttons on the radio).
73!
The GOOD news: I have been able to control power level, meter mode and vox.
The bad news: as expected, all functions don't fit. So mode change had to be dropped (but it has dedicated buttons on the radio).
73!
ATtiny2313, bascom-avr and serialin interrupts
Since I am apparently not able to receive data from the FT817 with an unbuffered input on the ATtiny2313 HW USART, I decided to try the buffered way.
Remembering my assembler courses, I was prepared to deal with interrupts (URXC, "receive complete", on the ATtiny2313) and ISR (interrupt service routine).
So I went on and modified my code:
Enable Interrupts
Enable Urxc
On URXC My_isr
But on compile, bascom-avr complained that:
"Error : 249 Line : xy ISR already defined [My_isr] , in File ..."
What? The answer is in the help file, under "CONFIG SERIALIN", "ASM" paragraph. Basically bascom owns the URXC interrupt, so you need to use ISCHARWAITING to peek into the buffer.
Remembering my assembler courses, I was prepared to deal with interrupts (URXC, "receive complete", on the ATtiny2313) and ISR (interrupt service routine).
So I went on and modified my code:
Enable Interrupts
Enable Urxc
On URXC My_isr
But on compile, bascom-avr complained that:
"Error : 249 Line : xy ISR already defined [My_isr] , in File ..."
What? The answer is in the help file, under "CONFIG SERIALIN", "ASM" paragraph. Basically bascom owns the URXC interrupt, so you need to use ISCHARWAITING to peek into the buffer.
04 November 2008
I received Hell
While MCW allows optical communications with simple equipment and doesn't require a computer, it does require two Morse-enabled operators.
In order to be able to involve more people in my (our) optical experiments, I wanted to try to send computer generated data over light. With all those soundcard programs and modes, there must have been a way to do it!
The people on the laser reflector were very helpful and provided a lot of info and encouragement. So I went on, my way.
Rather than implement a linear modulator that would also allow for AM voice (as suggested), I kept my original idea of simply squaring the audio drive and feed it to the LED. Sidebands are not an issue on a optical channel, where you're very likely to be alone.
For testing I recorded three 60" messages, two in RTTY (standard HAM baudot) and one in FeldHell. These were copied to an mp3 pen and played individually in an endless loop.
I built a squarer transmitter chain as follows:
... words started flowing on the screen.
At the end of the second row ("the binary install" words) I tried aiming the receiver somewhere else, simulating path attenuation: the text is still visible and in extreme situations can be reconstructed by the human brain processor.
I had very strong AC hum on the receiver side, that visualizes as slanted upgoing lines, but do not interfere too much with FeldHell.
Thinking of on-the-field experiments, RTTY would provide a constantly lit LED easier for aiming, while FeldHell blinks it causing more interest in occasional onlookers.
In order to be able to involve more people in my (our) optical experiments, I wanted to try to send computer generated data over light. With all those soundcard programs and modes, there must have been a way to do it!
The people on the laser reflector were very helpful and provided a lot of info and encouragement. So I went on, my way.
Rather than implement a linear modulator that would also allow for AM voice (as suggested), I kept my original idea of simply squaring the audio drive and feed it to the LED. Sidebands are not an issue on a optical channel, where you're very likely to be alone.
For testing I recorded three 60" messages, two in RTTY (standard HAM baudot) and one in FeldHell. These were copied to an mp3 pen and played individually in an endless loop.
I built a squarer transmitter chain as follows:
- AFSK (or whatever) source, mp3 pen or computer soundcard
- LM386 amplifier at max gain
- NPN switch to drive LED
... words started flowing on the screen.
At the end of the second row ("the binary install" words) I tried aiming the receiver somewhere else, simulating path attenuation: the text is still visible and in extreme situations can be reconstructed by the human brain processor.
I had very strong AC hum on the receiver side, that visualizes as slanted upgoing lines, but do not interfere too much with FeldHell.
Thinking of on-the-field experiments, RTTY would provide a constantly lit LED easier for aiming, while FeldHell blinks it causing more interest in occasional onlookers.
FT817 keypad - serial communication quirks
Wondering where the FT817 keypad has gone? Don't worry, I'm working on it every night. All the one-way features have been implemented and tested: direct frequency dial, mode change, VFO toggle and frequency presets. These controls only require to send data to the radio.
What was left instead requires to read two bytes from the radio, modify one or two bits and return them back.
While the software side has been implemented correctly, I didn't seem to be able to read bytes, thus writing back wrong settings to the FT817(ND). Many hours have been spent in visualizing on 8 LEDs (one byte) what was being received, processed and sent.
The most probable cause is to be found in the ATtiny2313 internal RC clock source. I did look for its beat at 8 MHz, but all I could hear was some wideband noise. Even at 4800 baud the tiny2313 is probably too off to read proper data.
I am completing a pre-production prototype with an external XTAL source. It will run at 14.7456 MHz, that gives a 0% error rate according to the uC datasheet. Theoretically it will be possible to increase the serial communication rate up to 38400 baud (FT817 maximum), but perhaps overall reliability would suffer.
If I manage to master these advanced controls, all sorts of customizations will be possible, from key-function remapping to new/different controls. A UK HAM has already asked me to have 60m presets on the keypad. The only limit is the chip program memory: 2kbytes.
What was left instead requires to read two bytes from the radio, modify one or two bits and return them back.
While the software side has been implemented correctly, I didn't seem to be able to read bytes, thus writing back wrong settings to the FT817(ND). Many hours have been spent in visualizing on 8 LEDs (one byte) what was being received, processed and sent.
The most probable cause is to be found in the ATtiny2313 internal RC clock source. I did look for its beat at 8 MHz, but all I could hear was some wideband noise. Even at 4800 baud the tiny2313 is probably too off to read proper data.
I am completing a pre-production prototype with an external XTAL source. It will run at 14.7456 MHz, that gives a 0% error rate according to the uC datasheet. Theoretically it will be possible to increase the serial communication rate up to 38400 baud (FT817 maximum), but perhaps overall reliability would suffer.
If I manage to master these advanced controls, all sorts of customizations will be possible, from key-function remapping to new/different controls. A UK HAM has already asked me to have 60m presets on the keypad. The only limit is the chip program memory: 2kbytes.
Subscribe to:
Posts (Atom)
