Thanks David, My preference is new hardware too, for several measures of "better performance".
> Re CPU load I haven't measured the codec alone but I estimate about half a floating point stm32, so 80 MHz or so. We run the entire FreeDV stack (modem, codec, FEC, drivers, protocol) in a 168 MHz stm32f4 OK (half duplex). It would be worth measuring this, we have quite a few tests in codec2/stm32. As I mentioned to Glen, I intend to get an L4 and test the performance on there, but I will likely get an STM32F4 Discovery as reference hardware and can then measure performance and try optimise if possible. I think it would be good general knowledge to know what the minimum requirements are to run the Codec. > I'd suggest doing the protocol and DSP on one uC, save you a lot of interfacing hassles. That's what we do. The chips are cheap. This is our ideal scenario too, but it's a matter of balancing other features and the controllers available, without having to step up to the next tier and then have a controller too overspec'd for our needs that then fails on our low power goals. > The codec DSP is all floating point, happy to work with you if you want to try some fixed point porting. This would involve writing a bunch of tests to verify float versus fixed. You might get some speed up by using SIMD instructions, but in general it takes more MIPS in fixed point than float, so it's likely the MIPS (and hence clock speed requirements) will go up. As per (2), the chips are cheap, so might not be worth the bother. As you point out, it might not be worth the bother. I tend to agree. It's mostly a thought experiment at this stage, and probably a common one that gets brought up a lot. I suspect the reason Bruce brought up the point that the work isn't going to be done for free by the community is because it gets mentioned often. The reason I was considering going with fixed point or integer math was because the algorithm behind Codec 2 seems to be tightly bounds constrained in a lot of places which could lean to using a multiplier and then doing everything as shorts for example. This probably would not scale well on an STM32 for the reasons you already mentioned, and also for the reason that the FPU on the STM32 is already quite efficient and has an extra 32 registers which do not collide with the rest of the application, so there are some strong wins keeping it floating point. However, if it was integer math it might be easier to port to an FPGA. I noticed a lot of loop and copy in the source at a short glance and thought those paths may optimise well if paralleled. Anyway, now I'm rambling. The Raspberry PI option looks good, I'll have a look at that. My little ham group have spoken about the prospects of a repeater, either on a mountain or a balloon. A Raspberry PI would make for a good repeater I imagine. Cheers, Josh On May 14, 2021, David Rowe <da...@rowetel.com> wrote: > Hi Josh, > > Yes I am in general agreement with Bruce's comments. Last I heard > (about 1 month ago) the m17 project have put their own custom hardware > development on hold and are focusing on ports to COTs HTs. > > I'm quite keen on the custom open hardware approach because: > > (i) re-use of COTS hardware involves a lot of pain, especially around > licenses, closed firmware and not-quite-right, undocumented hardware. > I'd rather we design what we want, or at least a custom, open source > radio deck that firmware developers can really run with. > > (ii) I'm a modem nerd and we can get better performance with custom > modem waveforms - many of the current crop of modems (DMR/Fusion) are > 10dB off theory due to their waveform design. That's 10x the battery > life or 10x the Tx power being thrown away. > > But I digress. To your questions: > > 1/ Re CPU load I haven't measured the codec alone but I estimate about > half a floating point stm32, so 80 MHz or so. We run the entire > FreeDV stack (modem, codec, FEC, drivers, protocol) in a 168 MHz > stm32f4 OK (half duplex). It would be worth measuring this, we have > quite a few tests in codec2/stm32. > > 2/ I'd suggest doing the protocol and DSP on one uC, save you a lot of > interfacing hassles. That's what we do. The chips are cheap. > > 3/ The codec DSP is all floating point, happy to work with you if you > want to try some fixed point porting. This would involve writing a > bunch of tests to verify float versus fixed. You might get some speed > up by using SIMD instructions, but in general it takes more MIPS in > fixed point than float, so it's likely the MIPS (and hence clock speed > requirements) will go up. As per (2), the chips are cheap, so might > not be worth the bother. > > 4/ Another approach for a club project is to base in on a Rpi. Some > UK Hams have built a neat HF FreeDV project: > > <https://warc.org.uk/?page_id=123372> > > and I've done some work with VHF data using RpiTx and RTLSDR, it > could easily run voice too. Battery consumption would be a bit high > for a HT, but you get a lot of functionality quickly. > > Cheers, > David > > On 14/5/21 7:34 am, Josh Lloyd via Freetel-codec2 wrote: > > Hi David & freetel-codec2, > > > > Firstly I would like to express a great appreciation for Codec 2, > > it's excellent to see an open-source codec in this low bitrate > > space! > > > > I have a question about the performance of the algorithm on > > embedded hardware. A collection of friends from the local amateur > > radio club have got together to try build a digital radio hand-held, > > essentially a walkie-talkie. This is to strengthen our understanding > > of digital radio, and to practice our electronics engineering. > > > > I came across your algorithm when looking for free open-source > > codecs that could be used with a low bitrate, and I noticed that you > > already had this working on the SM1000 which runs an STM32F4. I > > understand that the CPU is also computing the baseband for TX and > > RX, so there is some spare headroom outside of the codec. My > > question is how much headroom is available, and what clock rate do > > you run the SM1000 at to get the necessary performance? > > > > The team and I were postulating using an STM32L4 for our radio > > since it offers some very low power modes which are ideal for a > > battery powered device, but I am concerned that the 48MHz clock will > > be insufficient to run Codec 2. I intend to have a separate > > controller handle the packet radio, so that chore is lifted off the > > main processor. > > > > Can you provide any insight into how Codec 2 currently performs and > > at which clock rate does it fail timing? Further, is there any > > reason to suspect that using fixed point or integer multiplication > > may increase the performance? > > > > Thanks again to all those involved with Codec 2; and for your work > > on the thesis before it David, as well as the talks you've provided > > to the wider community. > > > > Kind regards, > > Josh > > > > > > _______________________________________________ Freetel-codec2 > > mailing list Freetel-codec2@lists.sourceforge.net <mailto:Freetel- > > cod...@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
