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