Hi David,

thanks for the response. I already got in touch with Don. Looking at the
much longer frames for 700D (160ms vs 40ms) I am considering to go for
the short interface in order to save some memory so that we may benefit
from Dons work on getting 700D to work on STM32F4xx. While some users
have STM32F7 or STM32H7 processors which have 512k of RAM at least, the
majority of the UHSDR users is still using the STM32F407 with 192k RAM.
To have any chance of 700D on these machines, we have to keep the memory
usage as low as possible. For the moment I decided to go with the
existing interfaces and see what we can get out of it.

The question remaining for me: Is there an technical advantage in using
IQ directly (better reception)?

Regards,
Danilo


On 10.02.2019 01:41, David Rowe wrote:
> Hi Danilo,
>
> Don has been doing some fine work on porting 700D to the stm32, and is
> nearly finished.  This has involved optimisation to reduce run-time
> memory usage. One of the changes was to use shorts rather than floats to
> save memory, and the current version just supports real valued signals
> for 700D.
>
> Danilo - Don has also developed an extensive, automated unit test system
> for the work he has done, under stm32/unittest.  The tests run on a
> Discovery board.
>
> Don - Danilo's SDR runs entirely on a stm32 (no external SSB radio).
> Previously, when using FreeDV 1600, his team passed complex valued
> samples to the FreeDV API.  IIRC Danilo is using a more modern stm32
> variant with more memory.
>
> So - we need complex valued support for 700D.  These could be complex
> shorts or floats.  One possibility:
>
> (i) modify freedv_shortrx(), freedv_comprx_700d() and the ofdm.c
> functions called to work with complex short samples (hopefully without a
> big impact on memory).
> (ii) modify freedv_comprx() to do a float to short conversion and call
> freedv_shortrx()
>
> However I'm open to suggestions (and patches) :-)
>
> Cheers,
> David
>
> On 09/02/19 19:43, Danilo Beuche wrote:
>> Hi,
>>
>> as you may know we have FreeDV 1600 support in the STM32 based TRX since
>> a while. Now I am finally aiming at integrating the 700D mode.
>>
>> For FreeDV 1600 we did not use the freedv_rx / freedv_tx calls as we
>> have float i/q data at hand due to the internal signal processing in the
>> rest of the SDR. So the freedv_comprx/freedv_comptx are used.
>>
>> I noticed that the 700D is not integrated in the
>> freedv_comprx/freedv_comptx functions. Now there are a number of questions:
>>
>> 1.I think instead we have to call freedv_shortrx which expects audio
>> samples instead of IQ. Is that correct?
>> 2. Should we go for all modes to do a demodulation first and then pass
>> audio data to the freedv_rx/freedv_tx which involves back converting the
>> data to float data?
>> 3. Or is there a benefit to pass IQ data directly to those modes which
>> support it?
>>
>>
>> In addition, are the improvements 700D for low performance processors
>> mentioned in http://www.rowetel.com/?p=6413 already integrated in the
>> source code? I guess so, but just want to be sure, since I could not
>> find support for the 700D mode directly in the SM1000 source.
>>
>>
>> Regards,
>> Danilo
>>
>>
>>
>>
>>
>>  
>>
>>
>>
>>
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-codec2@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2


_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to