SatPC32 works similar as Instant Tune (see Anthony Monteiro's detailed answer):
Thank you Anthony and Erich for your replies. I'm always impressed by the generosity of this list's members.
During the past week I've spent hours debugging my code because it was originally supposed to work the way that you have both described. Actually it did, or at least I thought it did, but that was before I bought a laptop computer and a USB to serial converter. The code has been updated many times during the past eight years and during one of those updates I changed the user interface so that the user had to stop the tracking during manual tuning; effective but clumsy.
Reading the FT-847's receiver frequency originally caused me some frustration. I had included a delay after each read and write command because the FT-847 doesn't return a command acknowledgement. While writing this reply I realised that instead of a delay I shroud be waiting for the serial port to receive five bytes from the radio.
This has turned out to be more reliable but I still get occasional read errors and I feel that it's due to the USB to serial converter. When an incorrect frequency value is read, at one second intervals, the same value is reread from the serial port buffer each second until the tuning knob is moved again. Maybe the read command is working correctly and instead it's the write command that instructs the radio to output it's frequency that's not working reliably.
I remember reading about some sort of delay that the FT-847 requires but I cannot remember what it was all about. It could be important.
A lecturer once told a class that I attended that explaining a problem to anyone, even your dog if no one else will listen, often leads to an answer. It's helping in this instance, but not enough to lead me to the final answer.
To add to my frustration, my ISP has made changes to their mail server which now prevents me replying to any e-mails that are outside of their domain. I have a workaround but it's a real pain.
Thank you Wayne for your thoughts on frequency drift. I spent many hours listening to AO40's beacon and did manage, eventually, to get the drift under control.
-- Regards, Phil.
On Jan 28, 2008, at 1:00 AM, [email protected] [email protected] wrote:
Reading the FT-847's receiver frequency originally caused me some frustration. I had included a delay after each read and write command because the FT-847 doesn't return a command acknowledgement. While writing this reply I realised that instead of a delay I shroud be waiting for the serial port to receive five bytes from the radio.
This has turned out to be more reliable but I still get occasional read errors and I feel that it's due to the USB to serial converter. When an incorrect frequency value is read, at one second intervals, the same value is reread from the serial port buffer each second until the tuning knob is moved again. Maybe the read command is working correctly and instead it's the write command that instructs the radio to output it's frequency that's not working reliably.
I remember reading about some sort of delay that the FT-847 requires but I cannot remember what it was all about. It could be important.
Phil,
Don't know if you're a "linux guy" or not, but the "snooper" package available on Debian Linux and derivatives, and certainly available upstream somewhere in source format for compiling on any other Linux system is a nifty tool for debugging such things.
Figured I'd share. I ran across it in the package list one day quite literally by accident, (I was looking for other "snooping" tools like tcpdump and similar) and realized it was the perfect tool to allow me to become my own worst protocol analyzer. :-)
It's kinda addictive to hook it up between serial devices you're not debugging and watch what's going on, too.
Great tool. Simple, effective, and free.
(By the way, it's not installed on the machine below, thus the "unsatisfied" dependency... this is just a text capture of the package manager tool (aptitude) on one of my Debian machines, showing the full description. Ignore the other cruft...)
-------
--\ snooper < none> 19991202-4 Description: Captures communication between two external serial devices Snooper passes data transparently between two serial (RS232C) devices, capturing and logging the data and occasional comments you want to insert into the logs.
It is useful for debugging or analyzing the communications protocol between two devices that would normally be connected directly to each other, e.g. a digital camera and a personal computer. By sitting "in the middle" (after you connect the two devices to serial ports on your Linux machine) snooper is able to capture data traveling in either direction while also passing it unmodified to the other device.
It is also possible to operate with a single serial device, using your console and keyboard as the second device.
Tags: admin::hardware, interface::text-mode, role::program, scope::utility, uitoolkit::ncurses Priority: optional Section: comm Maintainer: David Coe [email protected] Compressed size: 16.6k Uncompressed size: 42.0k Source Package: snooper --\ Depends --- libc6 (>= 2.3.5-1) --- liblockdev1 (UNSATISFIED) --- libncurses5 (>= 5.4-5) --- Packages which depend on snooper --\ Versions p 19991202-4
-- Nate Duehr [email protected]
----- Original Message ----- From: "Nate Duehr" [email protected] To: "Amsat-Bb" [email protected] Sent: Tuesday, January 29, 2008 6:18 PM Subject: [amsat-bb] Re: Satellite tracking programming ideas
Phil,
Don't know if you're a "linux guy" or not, but the "snooper" package available on Debian Linux and derivatives, and certainly available
Thanks for the reply Nate, I'm not a Debian user (dare I admit to being a loyal Mandriva supporter?) and as soon as I can establish an Internet connection I'll search for snooper.
I've been thinking some more about this serial problem and wondering if the radio might be at fault or, more likely, that I should be doing something between read frequency commands.
If I read the frequency once per second while spinning the tuning knob, occasionally I'll see an incorrect value. That same value persists until the knob is moved again. I can see the problem but not the answer.
Regards, Phil.
At 10:57 PM 1/30/2008, Phil wrote:
... I've been thinking some more about this serial problem and wondering if the radio might be at fault or, more likely, that I should be doing something between read frequency commands.
If I read the frequency once per second while spinning the tuning knob, occasionally I'll see an incorrect value. That same value persists until the knob is moved again. I can see the problem but not the answer.
Hi Phil,
Here are a few suggestions.
1. Try putting a loopback plug instead of the radio (TXD to RXD) and sending contiguous 256 byte blocks. Use an incrementing pattern so you can see if there are any errors as they come back in. You should be able to do this indefinitely (i.e. test it for several hours) with no errors
2. Are you using 4800 bps, 8 data, no parity, 2 stop bits?
3. Are you sending the 5 byte commands contiguously (i.e. loading up the UART FIFO?)
4. Do you check for any UART errors that might be detected?
If I can think of anything else, I will let you know.
73, Tony AA2TX
On Jan 31, 2008, at 8:17 PM, Anthony Monteiro wrote:
At 10:57 PM 1/30/2008, Phil wrote:
... I've been thinking some more about this serial problem and wondering if the radio might be at fault or, more likely, that I should be doing something between read frequency commands.
If I read the frequency once per second while spinning the tuning knob, occasionally I'll see an incorrect value. That same value persists until the knob is moved again. I can see the problem but not the answer.
Hi Phil,
Here are a few suggestions.
- Try putting a loopback plug instead of the radio (TXD to RXD) and
sending contiguous 256 byte blocks. Use an incrementing pattern so you can see if there are any errors as they come back in. You should be able to do this indefinitely (i.e. test it for several hours) with no errors
See Phil? That guy who taught you to talk to yourself when working through problems, was RIGHT!
(GRIN!)
Sigh... loopback plug... why didn't I think of that?! We do this DAILY in telco... (grumpy look...)... when the bits aren't acting right... see if you can talk to yourself.
The old telco joke... telco engineer goes to the firing range for his first day of shooting ever, can't hit anything, holds his hand up in front of the gun and pulls the trigger, blowing a hole in his hand...
"Trouble's not at my end! Must be down-range!"
-- Nate Duehr, WY0X [email protected]
-
Anthony Monteiro -
Nate Duehr -
Phil -
phillor＠telstra.com