Re: [Flexradio] Linux jDttSP
Hi Frank, Frank Brickle wrote: One of the things we're eager to find out is whether running the system entirely from ram disk will iron out some of the glitches associated still with using jsdr on a totally vanilla OS configuration, that is, with no low-latency patches, not running jack as root, and so on. This is very much what I am after. On the EPIA mini-atx, I am using an IDE-CF adapter with a 1GB CF card replacing the HD. Last weekend I have installed the base Debian Linux on it. I want to load a RAM disk kernel image from a diferent partition on the CF. For preserving data, I will try using a tiny raw partition on the CF and do direct I/O on the raw device. This would prevent any filesystem-related overhead. I will post the results on the reflector. 73, -- Edson
[Flexradio] Linux jDttSP
Good Evening! This is a question to Bob or Frank regarding jDttSP on Linux. I am trying to get a Qt-based GUI implemented to control jDttSP and have noticed that the spectrum data was not being correctly written to the spectrum FIFO. After some tracing, I've found that the problem was due to the fact that the window[] function array for the spectrum FFT was not being initialized. For testing I've initialized the window[] in init_spectrum() for the moment. Later I may include it in update.c. Now I have spectrum data coming out of the FIFO, but I've noticed that when setting the spectrum to PRE_FILT, the spectrum slides on the frequency axis following the setOsc setting. Trying SEMI_RAW does not work unless I set the mode to SPEC (setMode SPEC). But this changes the audio filtering and does not change the spectrum sliding behavior. One more thing I have noticed is that there is no change in the demodulator when I set the mode to USB or LSB (setMode USB|LSB). The only way I can switch SSB sidebands is by modifying the filter passband to negative values. My questions are: 1. Is the initialization of the window[] function left out in the Linux code? 2. Would there be a way to get a snapshot of the full 48 kHz raw complex spectrum without any interference from the tuning? 3. Is the USB/LSB behavior correct? Many thanks, -- Edson, pu1jte, n1vtn, 7n4ncl
Re: [Flexradio] Linux jDttSP
Edson -- Yipes! I can't thank you enough for pointing this out. We've had a couple of other reports about problems with the spectum output and have been going nuts trying to figure out what was going on, because I have been unable to duplicate the problem. There was a lengthy process of negotiation back and forth between Bob and myself concerning exactly what would go where in the spectrum computation, so that we'd have something that worked on both the Linux and Windows sides. It was my job ultimately to reconcile them in the codebase. Just at the time this was happening there were big problems at SourceForge with updates to CVS that got dropped on the floor. In short, the wrong version (half-corrected) was the one that got into CVS. It was pure sloppiness that I did not go back and test the CVS version that finally showed up. My sincerest apologies. I'm not going to correct the CVS at this time since, first, you've made the correct fix, and second, because there is a major new release coming out shortly. We're switching to FFTW3 and the code and data structures associated with all those computations are somewhat different. Now, to your questions. [1] *My* Linux version is correct, and yours isn't, because I screwed up. No surprise there. [2] The place to get the raw spectrum is not inside jDttSP but rather from the jack ports. If you need it inside jDttSP it can easily be provided, depending on what you're going to do with it. [3] The USB/LSB behavior is exactly as you describe. Switching sidebands is actually accomplished above jDttSP merely by altering the filter settings as you have done. 73, and again, many thanks. Frank AB2KT Edson Pereira wrote: Good Evening! This is a question to Bob or Frank regarding jDttSP on Linux. I am trying to get a Qt-based GUI implemented to control jDttSP and have noticed that the spectrum data was not being correctly written to the spectrum FIFO. After some tracing, I've found that the problem was due to the fact that the window[] function array for the spectrum FFT was not being initialized. For testing I've initialized the window[] in init_spectrum() for the moment. Later I may include it in update.c. Now I have spectrum data coming out of the FIFO, but I've noticed that when setting the spectrum to PRE_FILT, the spectrum slides on the frequency axis following the setOsc setting. Trying SEMI_RAW does not work unless I set the mode to SPEC (setMode SPEC). But this changes the audio filtering and does not change the spectrum sliding behavior. One more thing I have noticed is that there is no change in the demodulator when I set the mode to USB or LSB (setMode USB|LSB). The only way I can switch SSB sidebands is by modifying the filter passband to negative values. My questions are: 1. Is the initialization of the window[] function left out in the Linux code? 2. Would there be a way to get a snapshot of the full 48 kHz raw complex spectrum without any interference from the tuning? 3. Is the USB/LSB behavior correct? Many thanks, -- Edson, pu1jte, n1vtn, 7n4ncl ___ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz
Re: [Flexradio] Linux jDttSP
Hi Frank, Thanks for the quick response. Frank Brickle wrote: Edson -- Yipes! I can't thank you enough for pointing this out. We've had a couple of other reports about problems with the spectum output and have been going nuts trying to figure out what was going on, because I have been unable to duplicate the problem. There was a lengthy process of negotiation back and forth between Bob and myself concerning exactly what would go where in the spectrum computation, so that we'd have something that worked on both the Linux and Windows sides. It was my job ultimately to reconcile them in the codebase. Just at the time this was happening there were big problems at SourceForge with updates to CVS that got dropped on the floor. The problem actually pushed me to look into the code to find out how things work. In short, the wrong version (half-corrected) was the one that got into CVS. It was pure sloppiness that I did not go back and test the CVS version that finally showed up. My sincerest apologies. No need for apologies. On the contrary, I would like to thank you and Bob for the superb work you have done. It is quite fun to play with sdr under Linux. I am in the process of implementing a stand-alone little machine based on the VIA EPIA mini-atx mother board and the control application I am implementing is the first piece of a remote controlled SDR-1000 + little DSP-dedicated computer. I'm not going to correct the CVS at this time since, first, you've made the correct fix, and second, because there is a major new release coming out shortly. We're switching to FFTW3 and the code and data structures associated with all those computations are somewhat different. That is very exciting! I am tempted, but am not going to ask for when the release will be! :-) I know how hard it is to get software releases out. Can you tell us a little about the new goodies in the new version? Now, to your questions. [1] *My* Linux version is correct, and yours isn't, because I screwed up. No surprise there. No problem at all. I just wanted to confirm that I was not doing something stupid. [2] The place to get the raw spectrum is not inside jDttSP but rather from the jack ports. If you need it inside jDttSP it can easily be provided, depending on what you're going to do with it. The way it is now does work quite nicely. I was planing a large 4096-pixels panadapter, but instead of scrolling the spectogram image, I can leverage jDttSP to do it for me. I have some old code for a spectogram I wrote some time ago and will adapt it for working with jack. [3] The USB/LSB behavior is exactly as you describe. Switching sidebands is actually accomplished above jDttSP merely by altering the filter settings as you have done. Ok. For TX, would the behavior be the same or would the LSB/USB mode change anything? Thanks again, 73, -- Edson
Re: [Flexradio] Linux jDttSP
Edson -- Thanks for being patient :-) I am in the process of implementing a stand-alone little machine based on the VIA EPIA mini-atx mother board and the control application I am implementing is the first piece of a remote controlled SDR-1000 + little DSP-dedicated computer. Wonderful. This is very much what we were hoping would happen. Please keep us informed about how it's going. One of the things we're eager to find out is whether running the system entirely from ram disk will iron out some of the glitches associated still with using jsdr on a totally vanilla OS configuration, that is, with no low-latency patches, not running jack as root, and so on. Can you tell us a little about the new goodies in the new version? Unfortunately there's not much that will be dramatically obvious from the outside, apart from better performance. A lot of it is simple clean-up of the source and overhaul of the source directories. A certain amount is making convenient at the user level some capabilities which have been unused so far, like multiple receivers and the aux signal buses. There's a little bit of syntactic sugar on the update commands which makes them selectively recordable and replayable. Basically what it means is that you can get the radio to a desired state, save that, and restore it at will, without a console. An elementary facility, not meant to replace real memories or a database. There are some new experimental features like wavelet noise mitigation and MIDI input to the keyer. Unfinished but there to play with. If Bob is comfortable with it, the new mode that implements a soft transponder. Maybe the more interesting gadgets are outboard of jsdr, strictly speaking. There's a jack-to-python module, a test signal generator, and a couple of jack clients to assist in compressing the user-side audio streams and streaming them over LAN. Basically it's window dressing on what amounts to a thorough course of software-engineering hygeine and regualar professional care, like a heavy dose of Listerine. Ok. For TX, would the behavior be the same or would the LSB/USB mode change anything? RX and TX are completely symmetrical, except for a small processing stage on TX which eliminates residual DC. This is separate from the DC blocker on TX audio input which is meant to compensate for crummy soundcards. Very 73 Frank AB2KT
