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> 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> 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 >> 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
