First of all apologies if this has been sent to the wrong fldigi mailing list.
 I am working on a project to add support for a cheap software defined radio 
based on a chipcon cc1020 to fldigi. There are details of the project here

 http://ukhas.org.uk/guides:chipcon_cc1020_software_define_radio

https://github.com/Laurenceb/dl-fldigi

The existing playback in vanilla fldigi uses a delay function that inevitably 
delays for slightly longer than necessary, this created a problem for my 
application,
as data would back up in the named pipe used to pass the resampled data to 
fldigi in wav format. I have attempted to add support for a new "stream" 
function 
that eliminates all delays. Unfortunately this has resulted in a weird bug that 
I have been unable to fix; when the stream checkbox is unselected the UI stays 
responsive, but it appears the backend processing in fldigi hangs, as the 
waterfall display stops scrolling and cannot be restarted.
 This only occurs when using named pipes, if i attempt to open a .wav file with 
the new stream checkbox, there are no apparent problems - it is possible to
 start and stop playback at any point (although the data is processed extremely 
quickly using 100% cpu - as would be expected as the reads never block).
It is however possible to use the SDR without issue (apart from the obvious 
buildup of data in the pipe) using playback. So to sum up, this bug only 
appears 
when unchecking the new stream checkbox after having used it to playback from a 
named pipe. It should also be borne in mind that the named pipe is 
immediately closed for writing as soon as my resampling program receives 
SIGPIPE - indicating that fldigi has closed the pipe for reading. I have 
attempted 
to use strace to debug, and it appears that the UI along with file open and 
close is still working after the waterfall hangs - i can reboot my SDR hardware 
and
 attempt to reconnect to the named pipe with fldigi and the file open appears 
in the strace log, but the waterfall never restarts and no data comes out of the
 modem. At no point is fldigi using excessive cpu either. 
 I am not a c++ developer, and am not familiar with the fldigi source, so I 
though someone here might be able to offer their assistance.
 Thankyou for your time

Laurence BlaxterThis message and any attachment are intended solely for the 
addressee and may contain confidential information. If you have received this 
message in error, please send it back to me, and immediately delete it.   
Please do not use, copy or disclose the information contained in this message 
or in any attachment.  Any views or opinions expressed by the author of this 
email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
_______________________________________________
fldigi-alpha mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/fldigi-alpha

Reply via email to