Don't panic. After you've seen the optical receiving system, the transmitter will look horrible.
The plate is a CD-ROM player cover, bent upwards to hold a clothes peg. The transmitting LED is loaded there. The 488 Hz tone is generated with the usual XTAL+divider chain that drives a 2N2222A (the metallic cylindrical "thing").
In the center of the board there is a current generator (TO-220 transistor, the white cube, two red LEDs in place of a zener) with a jumper to provide two drive levels.
No tilt/turn controls were mounted since the path didn't require any precise beaming. Moreover the LED has a wide beam, so a simple tilt screw might be enough. No need for micrometric adjustments.
28 November 2008
26 November 2008
Terminator's eye
Finally we've made it! Simone and I could arrange a first complete equipment test.
The OPT201 receiver had been boxed (plastic) and prepared with a 31.8mm standard mount for telescopes. The MCW transmitter was simply mounted on a CD player cover (no picture available yet).
Since I could easily provide a circa 200m path, instead of looking for a dark grass field at <0°c, we decided to stay near the warmth of my place. When Simone looked out of the window was about to ask where the transmitter was. Then he said: "Oh, gosh, there it is! It looks like Terminator's eye!" A 10mm red LED looks pretty bright at 200m. I would compare it to a red light on the back of a car (5W@12V).
Simone brought the "antenna": a tripod and a modified half binocular (dia 50mm, F 300mm). Being experienced at looking for stars he pointed it in the right direction in a couple of minutes, then replaced the ocular with the receiver. Given the strength of the signal we tried staying inside and reducing ambient light (produced by a CFL, by the way) to minimize reflections on the window glass.
The 488 Hz tone was extremely strong and steady, effectively masking out any AC line harmonic. The screenshot below shows more than 50dB over background noise (look at the upper part). The screenshot was taken while my daughter was playing with the laptop keyboard and touchpad sitting on her Ikea drawing desk.
Then I recorded few seconds of signal for postprocess. Since the transmitter was square-wave modulated, many other harmonics were visible:
Note how weak even harmonics are, while odd ones are rather strong, in all the available recorded bandwidth.
Since Simone still had some time available we tried aiming at cars and stars (actually planets, Jupiter and Venus), but nothing could be heard.
Next test will be on a longer distance with some modulated information. Either one way in beacon mode or two-way, if a second CW operator is found. The quest for a proper field is open!
The OPT201 receiver had been boxed (plastic) and prepared with a 31.8mm standard mount for telescopes. The MCW transmitter was simply mounted on a CD player cover (no picture available yet).
Since I could easily provide a circa 200m path, instead of looking for a dark grass field at <0°c, we decided to stay near the warmth of my place. When Simone looked out of the window was about to ask where the transmitter was. Then he said: "Oh, gosh, there it is! It looks like Terminator's eye!" A 10mm red LED looks pretty bright at 200m. I would compare it to a red light on the back of a car (5W@12V).
Simone brought the "antenna": a tripod and a modified half binocular (dia 50mm, F 300mm). Being experienced at looking for stars he pointed it in the right direction in a couple of minutes, then replaced the ocular with the receiver. Given the strength of the signal we tried staying inside and reducing ambient light (produced by a CFL, by the way) to minimize reflections on the window glass.
The 488 Hz tone was extremely strong and steady, effectively masking out any AC line harmonic. The screenshot below shows more than 50dB over background noise (look at the upper part). The screenshot was taken while my daughter was playing with the laptop keyboard and touchpad sitting on her Ikea drawing desk.
Then I recorded few seconds of signal for postprocess. Since the transmitter was square-wave modulated, many other harmonics were visible:
Note how weak even harmonics are, while odd ones are rather strong, in all the available recorded bandwidth.
Since Simone still had some time available we tried aiming at cars and stars (actually planets, Jupiter and Venus), but nothing could be heard.
Next test will be on a longer distance with some modulated information. Either one way in beacon mode or two-way, if a second CW operator is found. The quest for a proper field is open!
Etichette:
optical
25 November 2008
FT817 keypad - real memories, not presets
It is still beta-code, but the keypad is now able to remember your favorite frequencies rather than offer you my factory programmed presets.
The ATtiny2313 has 2kB of program memory, 128bytes of RAM for program volatile variables and 128bytes of EEPROM for long term variables.
In the latter memory space, a program can write data that will survive power off of the microcontroller. This means the program can read something and store it for future use.
In the keypad application, the beta code allows to read the currently selected VFO frequency/mode and write it to a long-term memory area. Then with two keystrokes you can QSY back there. Even days or months after the keypad has not been in use.
Freq/mode information take 5 bytes, so we could store up to 128/5 = 25 memories. Since key combinations are limited and managing them "costs" code memory, I will probably implement these sequences:
- # followed by * followed by any other key assigns current freq/mode to that key
- # followed by any key recalls the assigned freq/mode, except for "#*"
So 15 custom memories will be available. Please note that only frequency and mode will be stored, nothing more. Not even the narrow filter setting.
One thing I noticed. In the BCB band (88-108 MHz) where WFM is the only allowed mode, recalling a memory will hang the radio requiring removal of power (not power-off, total unplug even from internal batteries). This is because I first set the mode, then the frequency. Doing viceversa might result in a different frequency if a change from SSB to CW is performed. Should be worth spending some code to set frequency, mode and then frequency again to avoid these situations, shouldn't it?
[that's why it is still beta code...]
The ATtiny2313 has 2kB of program memory, 128bytes of RAM for program volatile variables and 128bytes of EEPROM for long term variables.
In the latter memory space, a program can write data that will survive power off of the microcontroller. This means the program can read something and store it for future use.
In the keypad application, the beta code allows to read the currently selected VFO frequency/mode and write it to a long-term memory area. Then with two keystrokes you can QSY back there. Even days or months after the keypad has not been in use.
Freq/mode information take 5 bytes, so we could store up to 128/5 = 25 memories. Since key combinations are limited and managing them "costs" code memory, I will probably implement these sequences:
- # followed by * followed by any other key assigns current freq/mode to that key
- # followed by any key recalls the assigned freq/mode, except for "#*"
So 15 custom memories will be available. Please note that only frequency and mode will be stored, nothing more. Not even the narrow filter setting.
One thing I noticed. In the BCB band (88-108 MHz) where WFM is the only allowed mode, recalling a memory will hang the radio requiring removal of power (not power-off, total unplug even from internal batteries). This is because I first set the mode, then the frequency. Doing viceversa might result in a different frequency if a change from SSB to CW is performed. Should be worth spending some code to set frequency, mode and then frequency again to avoid these situations, shouldn't it?
[that's why it is still beta code...]
20 November 2008
FT817 keypad - automatic whistle
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!
- 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!
Etichette:
ft817
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
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)