- #FLDIGI FREQUENCY DISPLAY MANUAL#
- #FLDIGI FREQUENCY DISPLAY CODE#
- #FLDIGI FREQUENCY DISPLAY WINDOWS#
#FLDIGI FREQUENCY DISPLAY CODE#
Which, in turn, means your code only has about 3khz to work with.
#FLDIGI FREQUENCY DISPLAY MANUAL#
If you can't control the dial frequency, you're stuck with manual tuning, and FLDigi only has about 3khz of spectrum to work with. It's certainly possible to homebrew your own interfaces (I used to do it that way in Ye Olden Dayes of Yore). I bought USB cables on EBay for about $20 each for my Icom and Yaesu radios that take care of this. Obviously, this requires some wiring between your computer and your radio. You should be able to change bands and frequencies by clicking on the FLDigi user interface. Second step is to make sure that FLDigi can control the mode and frequency of your radio. If you can have a nice digital QSO with somebody with your setup in it's current condition, you're 1/3 of the way there. You should have your computer audio wired to your radio, and you should have all of your levels set right (ie, don't overdrive the transmit - if your ALC is moving, you've got it set too high). You should be able to have a PSK-31 conversation with FLDigi. If either of these aren't working, you have little to no chance of doing anything useful. First Things Firstīefore you can have any hope of using this library, you first need to make sure that FLDigi is installed and working correctly and that it's correctly talking to your radio. Input validation is on the very long list of To-Do items. For example, if you enter bogus fields for phg (for propnet), it'll either send bad data, or barf, depending on which value you hork up. There's a lot to be desired in things like validating and error-checking of user input. You can see what's changed from version to version by viewing the NEWS file.
Had to change it from a variable to a method, which would have broken any pre-existing code. Turns out I didn't think through the freq() method well when I first started out. In fact I've already broken that promise at least once. My intent is that library calls won't change, only new calls will be added, but at this point, it's early enough in the development cycle that I can't promise that. My time is limited, but I'll do what I can. Please provide feedback for features and bugs.
#FLDIGI FREQUENCY DISPLAY WINDOWS#
I do not own or currently have access to a Windows box, so your mileage may vary there. This code has been tested on Linux and OS/X, and so far, works perfectly. I'm now getting valid decodes on the PropNET site, so I'm assuming I've finally got it right. I was using the wrong CRC16 checksum (Did you know there's more than one? I didn't, either). The second client is a PropNET client written in ruby that uses FLDigi as a modem. The first client allows you to send CQ from the command line, or to send any arbitrary text, using whatever frequency, carrier, mode, and modem you wish. I've also included a couple of demonstration clients. This gem makes all of this just a bit easier to use. The best documentation has turned out to be reading the FLDigi source. The documenation for the FLDigi API is, to put it kindly, a little lacking. But talking directly to the XML-RPC API is a bit of a pain in the ass from random ruby code, so I wrote a gem to abstract it a layer, and remove some of the "ick" factor. The intent is to be able to use fldigi as a radio modem from ruby scripts (though it's useful for other tasks, as well, such as changing frequencies on a schedule, fetching the current radio frequency for insertion into a log, etc). Fldigi-ruby is a ruby gem for interfacing with the FLDigi API.