Yes and Yes, the data is “processed as received” with a little latency. Yes, the software/firmware is open source. Visit https://freedv.org/
Mel K0PFX From: Ammar Ahmad Khan <ammar0...@gmail.com> Sent: Tuesday, July 30, 2019 5:53 AM To: freetel-codec2@lists.sourceforge.net 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 <ammar0...@gmail.com <mailto:ammar0...@gmail.com> > 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 <ammar0...@gmail.com <mailto:ammar0...@gmail.com> > 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 <stua...@longlandclan.id.au <mailto:stua...@longlandclan.id.au> > 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 ~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 Freetel-codec2@lists.sourceforge.net <mailto: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
