Hi all, 1) This issue of power use. An answer for Ammar.
We are connecting this DSP appliance to a transceiver. In our Amateur Radio world, perhaps a Yaesu FT-857 which draws at least 1A on receive and 20A on transmit so 0.5A for our DSP box is entirely acceptable. 2) Availability of chips for hardware development. With chips already on available boards eg. Raspberry Pi Zero or the Discovery board series, why not use these? 3) Our FreeTEL Codec2 development is being done on Linux. You will need for our latest mode 2020, at least an Intel i3 or AMD with AVX/AVX2 instruction set based PC. The Intel Celeron series does not have AVX/AVX2 needed for "real-time" as you put it, for mode 2020. So, the source code is available, all the development software is freely available, GCC and Arduino etc.. Run up a Linux box, get some USB audio dongles and USB serial port adapters and a transceiver. Or perhaps two PCs, one for transmit the other for receive. Then move your USB hardware to a Raspberry Pi (or clone) and get it working there for your portable operation. First though, get your Amateur Radio license so you can talk to us over radio. Alan VK2ZIW On Tue, 30 Jul 2019 07:10:44 -0500, Mel Whitten wrote > Yes and Yes, the data is [UTF-8?]âprocessed as [UTF-8?]receivedâ with a > little latency. Yes, the software/firmware is open source. Visit > https://freedv.org/ > > Mel > K0PFX > > From: Ammar Ahmad Khan <[email protected]> > Sent: Tuesday, July 30, 2019 5:53 AM > To: [email protected] > Subject: Re: [Freetel-codec2] A Question about CODEC2 and FDMDV > > > And if we purchase an SM1000 FreeDV Adaptor, can we modify it's software ? > > > On Tue, Jul 30, 2019 at 3:47 PM Ammar Ahmad Khan <[email protected]> wrote: > > And Can anyone who has used FreeDV tell me that Is FreeDV a realtime > application? Like you continously can send voice from one end and will be > received in real time at the receiver ? > > > On Tue, Jul 30, 2019 at 3:36 PM Ammar Ahmad Khan <[email protected]> wrote: > > Nice to hear from you Stuart, you explained well. I also saw Rasberry Pie, it > doesn't have much audio ports , as you need more aux ports for this system. > Secondly, I don't require any USB, Ethernet, graphic displays or removable > storage. Only Debugging port and audio ports needed. > > > On Tue, Jul 30, 2019 at 3:25 PM Stuart Longland <[email protected]> > wrote: > On 30/7/19 6:19 pm, Al Beard wrote: > > Is there some reason why you want to run on less powerful hardware than > > a Raspberry Pi or > > clone? > > - Power consumption: a DSP or MCU will draw much less power than any > Raspberry Pi > > - Cost: Raspberry Pi is [UTF-8?]~AU$60⦠STM32F407VG as used in the SM1000 is > $20, there are other options from NXP/Freescale, TI, etc that are even > cheaper. > > - Availability: Broadcom won't sell you the bare SoC in the Raspberry Pi > unless you're buying tens of thousands of units. Closest you get is a > SoM like the Raspberry Pi Compute module. There are lots of MCUs on the > market, and most can be easily obtained in single units. > > - Complexity: MCU just runs bare-metal code from flash, Raspberry Pi has > a boot-loader, a kernel (usually Linux), an operating system (usually a > Debian derivative) *then* the application running on top. Much more to > go wrong. > > - Audio capability: the Raspberry Pi has no audio inputs, just one lone > stereo audio output. As that audio output shares its power source with > all other 3v3 peripherals, it has _lots_ of noise. (Found this out the > hard way on Friday evening.) More recent models have improved on this > somewhat, but your mileage may vary. > > > BUT: No USB ports, no Graphic display, no ethernet port. No easily > > replaceable program SD card. > > No SIMD instructions for any future modes such as LPCnet. > > Suppose the application Ammar has in mind does not require USB, > Ethernet, graphic displays or removable storage? Maybe such things are > undesirable. > > As for SIMD, you do realise that SIMD instructions were developed *for* > digital signal processing applications don't you? Maybe the TMS320C6713 > has different SIMD functions to what's used in LPCNet, but that doesn't > mean it can't be ported by someone who has a good foundation in the field. > > It really depends on what you're trying to achieve. If you want a > general-purpose, highly flexible system, the single board computers may > be a viable option. > > Brisbane WICEN recently did a RFID/APRS integration project, and I made > the decision to use the PocketBeagle over a smaller device like the > Arduino Mega on the grounds that the only thing the Arduino Mega had in > its favour was a couple of extra UARTs and a reduced power consumption. > > Given the radios and RFID readers we were going to be running *with* the > computers consumed orders of magnitude more power than the computers > themselves, I didn't see this as being that big issue. > > Long term, we may decide to port it over to a small MCU platform. We'll > see. The PocketBeagles are a bit under AU$40, and while the original > task could most definitely be done by an Arduino, it's looking like > we'll have to run a small database at the check-point, at which point > the PocketBeagle really starts to shine. > > We of course have the risk that sudden power down can corrupt an SD > card, however it's not a big problem in our situation to have a couple > of spare SD cards that can be quickly taken to a check-point. Plus, > there's always the pen-and-paper system as a back-up. > > If your aim though was to use a low-power radio like a Elecraft KX3 or > something and wanted a small embedded "modem" to do FreeDV however, the > SM1000 or something built on the TI DSP mentioned would definitely be a > more reliable option long-term, would have a lower hardware cost per > unit, and would consume less power. > > The trade-off is development cost. > > For us we needed to throw something together in a few week-ends. > Muggins wound up writing the foundations for an AX.25 stack in Python > (there are a few libraries, but they didn't want to play the game for > me), and I basically had a rudimentary system that could send APRS > messages via a standard KISS TNC. > > I could of course do what I've done so far in C on a microcontroller, > however it's looking like I'll need to access USB mass storage and embed > a database of some kind (right now I'm using SQLite3, but there are many > other options), things I don't fancy doing from a small microcontroller. > > So there's nothing wrong with Ammar going to a development board. If > the aim is to play with FreeDV it definitely is jumping in at the deep > end, however some people enjoy that sort of challenge. > > My thought would be to maybe have a look at the STM32F4 Discovery > development board, as that was the board used to actually develop the > SM1000 firmware. Once you poke it and see how it moves, it may be > possible to slowly port it over to the TMS320C6713. > -- > Stuart Longland (aka Redhatter, VK4MSL) > > I haven't lost my mind... > ...it's backed up on a tape somewhere. > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 --------------------------------------------------- Alan Beard OpenWebMail 2.53
_______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
