-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FreeDATA Feature Request 001 - FreeDV API support for custom OFDM raw data modes #46
Conversation
@DJ2LS - I've had a go at a non-table driven interleaver algorithm in C and Octave. I haven't tested it on the on (16200,9720) code yet as I don't have a waveform that uses that code, but the ctests pass so it works on a bunch of other codes. |
thanks, @drowe67 , as soon as I managed to access the API successfully via Python, I'll test a mode prototype which uses the 16200,9720 code, then we can test the interleaved algorithm, as well. |
@drowe67 , the gp interleaver might work, the modem didnt run into a crash with a 16200,9720 code. but it seems we have to adjust |
Yes we'll have to figure out a way to handle the filters. Suggest you disable them for now, |
The |
So run run time design of the LDPC code? Tricky, however it might be possible for the WiMax or DVSB2 (CML built in codes), as there is already an Octave function This would be a significant chunk of work, probably best placed in another feature request or PR. |
At least the intention is, modifying the amount of data bits of a code, like done with datac14 for example. It seems, this is important for mode designing when having limitations like a specific bandwidth for example.But I probably there is another way for doing this? |
If the effort is too big, we could also keep this in mind, gathering experience with the existing way of adjusting parameters, also building the environment, like documentation, first. Then focusing on this somewhen later. |
Ok OK - so a fixed code, but we vary the # of payload data bits used. Yep, that can be done easily 👍 |
@DJ2LS - I've worked out a way to set the number of used data bits per LDPC codeword auto-magically. |
@DJ2LS - I've had a first pass at making the Tx BPF config driven. You'll need to add:
to your Python OFDM_CONFIG structure. Example usage in Setting up the clipper requires some experimentation, I do it at the Octave simulation level. Some notes I had left for myself in |
Thanks, @drowe67 . Problem is actually, that I can't directly access filter_coeff.h, I could copy and implement it in Python so we can still use it, but if we could access the codec2 related files directly, this would be more mature I think. Is there a way, just providing a name of the corresponding filter, like this:
|
Another question is then the implementation of custom filters. How could this achieved? If the pointer to the filter on init would be used everywhere internally, this part could be outsourced, but with the problems mentioned before 🤔 |
@DJ2LS - I've just pushed a feature that dumps the OFDM config using the new
|
Thanks, @drowe67 thats definitely a usefull function! Problem with ctypes <--> C is, that it is hardly crashing when trying to open the codec2 instance, means I can't use the function as long as we don't have a running mode instance. |
@DJ2LS I got the tx bpf working. |
@DJ2LS has tested this by implementing a new, custom waveform. He worked through the Tx BPF and clipper adjustment steps. So ready for merge 🙂 |
Lets the advanced API programmer configure a OFDM raw data mode at init time, without having to modify libcodec2. It assumes the programmer understands how to configure the waveforms, use the waveform design spreadsheet, and has prototyped in Octave.
An example has been coded into
freedv_data_raw_tx
andfreedv_data_raw_rx
that takes the 4 carrier, 0.69 second durationdatac14
packet waveform as a template, and converts it to a 3 carrier, 0.92 duration packet:You can hear the difference in duration using
aplay
:TODO: