Re: [Freetel-codec2] SM1000
On 29/12/20 2:58 pm, Muhammad Usman Akbar wrote: I am taking about the following IC's. 1. TPS54329E used in the power circuit (12-15 VDC -> 5 VDC 2. STMPS2141 used in OTG USB interface 3. EMIF02-USB03F2 also used in OTG USB interface 4. LD3985M33R used in 5V to 3.3 V PS. Okay, so for (1) and (4)… any PSU capable of supplying the required current levels will do the job. You might need to identify any supporting circuitry around these parts, in particular the TPS54329E will have inductors and capacitors around it. Whatever part you replace the TPS54329E with, you may need to re-design that part of the circuit as it may require different value inductors/capacitors around it. An easy way out would be to switch that chip and surrounding parts with a 12V→5V 3A switch-mode module. As for (4), the LD3985M33R is a bog-standard 3.3V low-noise LDO capable of sourcing up to 150mA. Regards, -- 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
Re: [Freetel-codec2] SM1000
On 29/12/20 3:14 pm, David Rowe wrote: 2) If you don't intend to use USB OTG you might not need this. Just had a look at what that part is… https://www.st.com/en/switches-and-multiplexers/stmps2141.html Looks like that's more important if the SM1000 is acting as a USB host than as a USB device, particularly a USB device that has its own source of 5V. I'd suggest the probability of this being required is very small indeed. -- 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
Re: [Freetel-codec2] A Question about CODEC2 and FDMDV
On 1/8/19 11:46 am, Steve wrote: > It's Sicilian talk, Not taught in schools... :-) I studied A/D and D/A converters… Nyquist… aliasing… all that "fun" stuff! -- 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
Re: [Freetel-codec2] A Question about CODEC2 and FDMDV
On 1/8/19 12:00 am, Steve wrote: > How about a new repository for a KiCAD project to copy the SM1000 > support circuitry, e.g., A/D, D/A, PTT, LED's, etc, onto a RPi4 HAT. > Maybe include a +12 VDC connector to power everything. The A/D and D/A are built into the STM32F407. -- 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
Re: [Freetel-codec2] A Question about CODEC2 and FDMDV
On 30/7/19 8:36 pm, Ammar Ahmad Khan 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. Yeah, audio is a real sore point of the Raspberry Pi. Two solutions exist for bi-directional audio: - USB Audio - I²S FreeDV (GUI application) basically assumes you've got two sound cards, one which connects to the transceiver and the other to a speaker/microphone (or headset). With some code hackery, you might be able to do both with the same audio codec chip. (i.e. you may be able to say use the "left" channel for the operator, and the "right" for the radio) USB bandwidth isn't great on the Raspberry Pi either, best results are using a combination: USB for the operator and I²S for the radio. By the sounds of things though, you're targeting an embedded platform, so as I say, I'd be having a look at buying a couple of STM32F4 Discovery boards and playing with those. They're half the price of a Raspberry Pi, and closer to the platform you were originally looking at. https://www.st.com/en/evaluation-tools/stm32f4discovery.html Then you can debug it, get to understand how the code works in its native habitat, before moving it across to another platform. -- 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
Re: [Freetel-codec2] sm1000 and FreeDV 700D
On 17/7/19 8:10 pm, Frank Bendon wrote: Could it be something to do with trying to run it with a USB3 port? Wouldn't be the first USB 2 device to have issues with a USB 3 host. Lots of USB 2.0 devices seem to have issues, not sure whether it's fixable in device firmware or not. -- 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
Re: [Freetel-codec2] A Question about CODEC2 and FDMDV
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
Re: [Freetel-codec2] sm1000 and FreeDV 700D
On 17/7/19 6:16 am, David Rowe wrote: I had no idea the Windows world was so confusing! Isn't dealing with an OS that simultaneously wants to be CP/M, VMS and (more recently) Linux such fun?! -- 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
Re: [Freetel-codec2] A Question about CODEC2 and FDMDV
On 30/7/19 4:17 am, Ammar Ahmad Khan wrote: Hello. Can anyone suggest any hardware paltform for running a communication system with CODEC2 and FDMDV in it, and running it in real time… I'd be looking at something Cortex-M4F based… as that's what the SM1000 is based around (it uses a STM32F407). I'm not familiar with the specifics of the TMS320C6713 DSP in it, other than the fact that Wikipedia describes it as a 32-bit floating-point DSP. On paper, it should do the job, but I think debugging why it didn't is going to require someone who knows the DSP better than I do. -- 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
Re: [Freetel-codec2] A Question about CODEC2 and FDMDV
On 22/7/19 3:14 am, Ammar Ahmad Khan wrote: And can this system run on GSM ? "run on GSM" how? You could skip the FDMDV bit and just use CODEC2 to encode audio to be sent as GPRS, however why would you when GSM has an audio streaming feature built in? You could try running the FDMDV over that audio streaming system, but the vocoder in GSM is going to give you a very hard time as it will mangle the FDMDV modem tones something fierce! You're flogging a dead horse going that route. -- 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
Re: [Freetel-codec2] First pass at a schematic for a small, cheap radio that runs Codec2
On 26/5/19 2:17 pm, Steve wrote: > On Sat, May 25, 2019 at 9:55 PM Stuart Longland > wrote: >> >> Whilst tethered, you could then turn off WiFi and just use CDC-Ethernet >> to communicate between radio and phone which would further reduce power >> consumption. > > I think many are attracted to the ESP-32 for it's built-in wireless. > At least a lot of hobbyists mention that in their builds. Agreed, but it's not the only way to link a phone to a project, and is arguably a power-hungry way to do so. I think Expressif were working on a variant of the ESP32 which would have USB on board … it's a future enhancement I think worth considering. -- 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
Re: [Freetel-codec2] First pass at a schematic for a small, cheap radio that runs Codec2
On 24/5/19 5:31 am, Bruce Perens via Freetel-codec2 wrote: > Please see https://perens.com/2019/05/23/ht-of-the-future-new-design/ > I don't know anything about hardware design and did this one by myself. > So, please point out mistakes, etc. The idea of a smartphone-based transceiver sounds excellent. I would prefer this over a cross-band solution in many ways. My Kenwood TH-D72A is slowly falling to bits and whilst I've contemplated a replacement: there's nothing really compelling out there. This more open hand-held design I think is a step in the right direction. Just needs a 70cm band PA (which is easy enough to achieve with a kit). One thought though, with the battery life of modern phones these days, I'd suggest maybe including the ability to power the phone as well from the radio's battery might be worthwhile. Whilst tethered, you could then turn off WiFi and just use CDC-Ethernet to communicate between radio and phone which would further reduce power consumption. When used in areas with no cellular communications, the phone could be put in "flight mode" to avoid wasting power on running a 3G/4G/LTE radio that's not useful. -- 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
Re: [Freetel-codec2] LPCNet at 1700 bits/s
On 5/3/19 7:04 pm, Adrian Musceac wrote: > Thanks David and Gregory for explaining. > I'm very curious, if this works in combination with LDPC, where does it > fit within Shannon-Hartley. It could be one heap of coding gain to be > able to send 8 kHz audio information on a 2 kbit channel > > Is this even the right way to categorize it? Well, it's not a 8kHz arbitrary waveform, it's a very specific subset of possible waveforms that can be represented by that 2kbit channel. -- 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
Re: [Freetel-codec2] add OpenBSD support
On 16/1/19 7:22 am, Alan Beard wrote: Question for Jeroen, what advantages does OpenBSD give us? 1. simpler design with none of the cruft that Linux distributions are increasingly becoming dependent on. 2. due to the simpler design, it's therefore easier to audit all code for security vulnerabilities and instability. OpenBSD actually makes a very decent server/router, and I have used it as a desktop as well. The toolchain has some idiosyncrasies (they use an old version of `binutils`), but in general, what works, tends to work well. Linux is fine, and I use it as my primary OS, but one cannot deny that OpenBSD has got a legendary track record for security with its releases, and as the Linux distributions pile on the complexity in desktops (PolicyKit, ConsoleKit, HAL, systemd, … ohh my!), maybe the Church of Puffy actually have a point. :-) -- 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
Re: [Freetel-codec2] ARM SBCs with SATA - was: Ubuntu 18 can't install subversion
On 1/11/18 2:03 am, Ed W wrote: > Sorry for bringing up an ancient email, but I saw that it was topical > again recently > > Can I recommend the PCEngines APU devices for your requirement. They > aren't as cheap as the various "PIs", but they have a ton of horsepower, > MPCIe slots and SATA ports. Power is low, but not super low (5-10W). You > can use them with a decent SD card (PCEngines have some that can be put > into SLC mode for better wear resistance) or use a full MSATA SSD (or > the SATA port) Hate to nitpick, but the APUs are running AMD Geodes (APUs) or AMD GX-412TC (APU2s), both of these are x86 not ARM, which is what was being discussed. :-) That said, they're the only x86 machine I've struck which has schematics available and comes out of the box with the open-source CoreBoot firmware. https://www.pcengines.ch/apu2.htm So if ARM isn't a requirement, they are worth looking at. -- 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
Re: [Freetel-codec2] Message for Don Reid, develop on Banana Pi
On 09/10/18 12:09, Alan Beard wrote:
> *You'll find the stm32 libraries in /usr/local and the current code
> in /home/data/alanb*
> *or you can upload with the script.*
> *
> *
> *just ssh wsjt...@www.unixservice.com.au, pwd CENSORED*
Errm, how about Don just emails you his ${HOME}/.ssh/id_rsa.pub and you
append it to ~wsjtdev/.ssh/authorized_keys like Puffy¹ intended. :-)
That is *MUCH* safer for all concerned.
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
1. https://en.wikipedia.org/wiki/OpenBSD (the same mob that produce OpenSSH)
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Ubuntu 18 can't install subversion
On 07/08/18 10:54, Alan Beard wrote: > Also guys, I'm amazed, nobody seems to want a Pi with a high speed disk > interface. It's not that we don't want it, it's that most don't want the cost of such a beast. The Pi is cheap because they took an existing SoC meant for set-top-boxes and smartphones, high-volume devices with little need for I/O. It is because of the "high-volume" aspect of these chips' production that make it possible to produce a cheap computer. There are ARM chips that have these other interfaces, but there's less demand for such things in mass-volume products, so they're more expensive. https://www.compulab.com/products/sbcs/sbc-imx8-nxp-i-mx8m-single-board-computer/ is one that offers PCIe, yes, they sell for US$68, but I hope you have a use of 1000 of them. If you want individual ones, you're looking at US$204 or ~AU$280. ~$100 for a LGA1151 motherboard, another ~$80 for a CPU, ~$50 for some RAM, ~$30 for a PSU and ~$50 for a SSD: there's a similar spec x86 machine for about AU$310. When you consider that ARM SBC will require a PSU (the x86 machine includes this), suddenly the higher-end ARM SBCs aren't so compelling. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Microsoft purchases GitHub
On 06/06/18 00:43, Bruce Perens wrote: > Gee, Steve. Some of the world's most profitable companies are... in > SILICON VALLEY. Never been to America, so I could be very wrong here, but Silicon Valley is in the San Francisco Bay area, while Microsoft is in Redmond, Washington. From what I can see, there's a fair hike between the two. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Microsoft purchases GitHub
On 05/06/18 22:03, Tomas Härdin wrote: > RE: Microsoft, it's still a large for-profit company so I'd be careful > in trusting it So was Github before Microsoft bought it. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Microsoft purchases GitHub
On 04/06/18 13:23, Bruce Perens wrote: > Microsoft has purchased GitHub. This is not of concern for the codec2 > and FreeDV sources, since they are hosted on Sourceforge. I think Microsoft has come to the realisation that "if you can't beat 'em, join 'em". CodeProject really never took off, and from what I hear, Visual Source Safe was something of a practical joke. In order to avoid being an utter laughing stock, it more or less had no choice to take up Git, and as they failed before in trying to make a competing project site, their decision to buy up Github is not surprising. > Microsoft is not the evil empire it once was, and might even see fit to > sponsor some of my efforts to fight against royalty-bearing patents in > standards. Which is going to feel very strange if it really happens. But > GitHub is still too many resources of the Open Source community residing > in one place. This was never a good idea. True, but the beauty of git is that it's distributed. What isn't is the wikis and issues, but there are ways of capturing that and hosting those elsewhere. There are even bug trackers that will operate within a git repository directly. So long as commits are signed (and they should be if you care about people using your code), the mirror can be verified as being authentic. Look at how the Linux kernel team handled the breach of git.kernel.org: Linus just pushed his tree into Github and development kept going. The world barely noticed. I experimented with running Gitlab on my own hardware, but found it was rather a pig when it came to RAM usage. It would struggle to run on a host with 2GB RAM. That, and the fact that it couldn't "mirror" a remote repository unless you stumped up for the enterprise version was a deal breaker for me. Presently for my own "incubator" projects, I've been using Gitea, and found it to be much more lightweight. It would happily run with 512MB RAM for smaller repositories. For mirroring the Linux kernel, I found I needed more RAM and have it running fine with 2GB. It is a fork of Gogs, which is also worth looking at (although I found Gitea first). Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] 700D vs SSB Comparison
On 07/05/18 15:26, Alan Beard wrote: > *One point I see as missed. *We HAMs are not allowed encryption Not strictly true… in a bona-fide emergency or when controlling a remote automatic station, the ACMA rules permit it. (ACMA LCD section 8 3A; pages 9 and 10 of http://www.wia.org.au/licenses/assessor/documentation/documents/Radiocommunications_Licence%20Conditions_Amateur_Licence_Determination_2015.pdf) SSH over AX.25 to your digipeater up on a mountain top somewhere would be perfectly fine, as would a station being operated during a bushfire event using OpenPGP to encrypt peoples' personal data before "emailing" it via a digital radio network to some other party that might then relay it onto some emergency response group. It's in casual conversation, or those operating in countries that explicitly forbid it (e.g. USA) where it's strictly forbidden. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Codec 2 and Wavenet
On 22/04/18 20:04, tom sparks wrote: > > > On 22/04/18 13:23, Stuart Longland wrote: >> On 22/04/18 07:51, James Cloos wrote: >>>>>>>> "DR" == David Rowe writes: >>> >>> DR> http://www.rowetel.com/?p=5966 >>> >>> That is currently 403 Forbidden when using Seamonkey. >>> >>> If I removed the bit 'Lightning/5.4.5' from the user agent, but left >>> the rest of the ua the same, then it worked. >> >> I've observed this too… tried adding the RSS feed of that blog to my RSS >> reader and got a stack of 403s. Rather than try and debug it, I decided >> that this was a signal that my interest in the project was unwanted and >> left it. >> > its a thunderbird bug > <https://support.mozilla.org/en-US/questions/1166672> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1383530> No it isn't. This software strikes the same problem: http://github.com/sjlongland/tornado-news -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Codec 2 and Wavenet
On 22/04/18 07:51, James Cloos wrote: >>>>>> "DR" == David Rowe writes: > > DR> http://www.rowetel.com/?p=5966 > > That is currently 403 Forbidden when using Seamonkey. > > If I removed the bit 'Lightning/5.4.5' from the user agent, but left > the rest of the ua the same, then it worked. I've observed this too… tried adding the RSS feed of that blog to my RSS reader and got a stack of 403s. Rather than try and debug it, I decided that this was a signal that my interest in the project was unwanted and left it. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] IP protocol over FreeDV
On 25/03/18 13:00, Dean H (KC4KSU) wrote: > It’s good to hear someone else is looking at applying 6LoWPAN to amateur > radio. > > I’ve studied 802.15.4 a fair bit. I find the standard is growing beyond > an individual’s ability to manage. So I distilled the 802.15.4 frame to > the essential pieces. My result <https://github.com/dwhall/HeyMac> is > not 802.15.4 compliant, but it’s much more manageable for an individual > to understand and write code. My frame format will support RFC6282 > (header compress and UDP compression). I don't think 6LoWPAN over Bluetooth Low Energy confirms to 802.15.4 either. To be honest, a IEEE 802.15.4 is never going to be practical on amateur radio bands, and there's nothing to say we have to confirm. :-) > My target radio is the Semtech SX127X running in LoRa > <https://en.wikipedia.org/wiki/LoRa> mode. That’s a Chirp Spread > Spectrum modulation with selectable bandwidth from 7.8 to 500 KHz. It > has built-in FEC and supports payloads up to 255 Bytes. Not enormous > paylods, but twice that of 802.15.4. My first LoRa configuration is > (Bandwidth=250KHz, FEC code rate: 4/6, spread factor: 128). This > results is a data rate around 9000 bps. > > My current status is that I have a physical layer driver working and I’m > building the MAC layer. It’s time-slotted, but not channel hopping. > Time slots are 250ms to allow a full frame and an ack. The radio > boards <https://www.tindie.com/products/edwin/loragps-hat/> have a GPS > chip and synchronize to its Pulse-Per-Second (PPS). Ahh, so 433MHz. Over 1kB/sec data rates is nothing to be snorted at to be honest, even if it does take 250kHz of spectrum. My reasoning for using AX.25 equipment is largely because there's a lot of infrastructure already around. I have two stations capable of operating with it, and it's widely understood. I recognise that it's sub-optimal in terms of noise performance. A "FreeDV 1200" modem could conceivably run just as fast, and provide the long-distance hops between isolated networks via HF links. There's no reason why we can't route between such networks… or even the 433MHz system you're proposing -- it's all IP after all. :-) > In the MAC layer, I have an extended Beacon working. I’m experimenting > with what to put in the beacon at the moment. My next endeavor is to > create a MAC command for simple text messages. This is all still in > prototype stage. I’m coding in Python3 on a Raspberry Pi 3. Yes, I’m > getting millisecond-level accuracy with Python. I start range-testing > the 1/10th Watt radio modules this weekend. There are 1W modules if > this protocol proves promising. Sounds good. Nothing wrong with Python, especially at the prototyping stage. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] IP protocol over FreeDV
On 25/03/18 06:25, Bruce Perens wrote: > FreeDV voice packets are around 7 bytes per 40 milliseconds. Even a > single IPV6 /address /is twice the size, not to mention the rest of the > header. So, realistic expectations are called for. Header compression is > helpful. Retransmission of a TCP packet could easily be a 1500 or more > byte repeat, taking most of a second. The best mix of FEC to reduce > repeats while minimizing overhead is still open for your research. Actually, I have been looking at how 6LoWPAN does things. In particular, I've been working with OpenThread at work, and considered rejigging that to work within AX.25 UI frames which could be transmitted with existing AX.25 hardware for FM, or utilise the FreeDV modem for SSB. 6LoWPAN ordinarily runs over IEEE 802.15.4. There, they have a 128-byte limit on link-layer frames, and a radio network of nodes where not all nodes can directly communicate. For nodes within the mesh, they actually use a shortened address to abbreviate the IP address to help compress the header down, and the protocols typically used over 6LoWPAN are typically geared to keep the packet size down (e.g. CoAP instead of HTTP). If you do send a big packet, it gets fragmented. I don't think there's repetition of a single frame within that segment, so it'd be up to upper layers to re-send the lot. Forward erasure coding would help a lot there as the probability of us losing a packet is so much higher. Thread is officially supposed to work over 2.4GHz, but there's nothing to suggest it couldn't work on HF. We just have to do our own modem to replace 802.15.4, and rejig the crypto so that shared keys are used to authenticate (a message integrity code) instead of encrypt. In short though, I think it could work. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] question about codec2
On 07/12/17 21:39, Stuart Longland wrote: > I don't think any of us can, legally, even if we *did* have a copy of > the implementation. > > I think someone who had a copy of the CODEC contributed those samples. > They were not done by any of the core team. In fact, this confirms it: > I don’t have a AMBE or MELPe codec handy so I used the samples from the DVSI > and DSP Innovations web sites. I passed the original “DAMA” speech samples > found on these sites through Codec 2 (codec2-dev SVN revision 3053) at > various bit rates. Turns out the DAMA samples were the same for the AMBE and > MELPe samples which was handy. → http://www.rowetel.com/?p=5520 So it was taking the same uncompressed samples that DVSI/DSP Innovations produced, and encoding those with Codec2. So if you want the implementation that produced those MELP samples, you'll have to talk to DSP Innovations. I wish you luck! -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] question about codec2
On 07/12/17 21:35, Hamza KHEDDAR wrote: > I would like to do some contribution on codec2 and compare it to result > obtained if the contribution is done in MELP. since you have already > compare codec2 with MELP600 performances. would you please send me the > MELP600 implementation ?. I don't think any of us can, legally, even if we *did* have a copy of the implementation. I think someone who had a copy of the CODEC contributed those samples. They were not done by any of the core team. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] TDMA and digital voice
On 04/11/17 13:27, Alan Beard wrote: > In the DMR camp, in particular the TYT MD-380 and clones group, > we have a possible hand-held with downloadable firmware that > could support another codec. Good luck with that. It's theoretically possible, but I doubt the CPU in the MD-380 is brauny enough to do Codec2 real-time given it was chosen with the intent of using a specialised DSP (the AMBE+ chip) to do the signal processing. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] FreeDV GUI 1.2 on Linux, Fedora 23
On 12/05/17 07:38, Alan Beard wrote: > *My problem: > Transmit mic in.* Nothing on the "Level" bar-graph or the oscilloscope > screen. > > "Pulseaudio" from desktop "Settings" shows my mic is working. > > I can make an RDP session available for your testing though RDP on Linux > doesn't give mic and speaker. Very stupid question on my part… is FreeDV set to use PulseAudio for that part? If PulseAudio is hogging the sound device and FreeDV is set to use the sound device directly, it won't get a look in. I find the sound interface plugged into the transceiver *should NOT* be accessed via PulseAudio, which means going into the sound settings applet (e.g. `padevchooser`) and making sure that sound device is de-selected. The sound interface representing your "human" interface (e.g. headset or speaker/mic) *should* go through PulseAudio. As for RDP; it might be possible to expose a SPICE session instead, which does carry sound. RDP won't because a Linux RDP server is basically an X server, and X does not have sound. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] LoRa Modulation
On 28/02/17 11:24, David Rowe wrote: > We have managed to send HD images over 100km paths using just 50mW: > >http://www.rowetel.com/?p=5344 Quoting the site: > We were receiving 115 kbit/s data on just 50mW of tx power at ranges of over > 100km. Okay, silly question, how wide, approximately, was the transmitted signal? 115kbps is bloody good for 70cm FSK, giving D-Star 23cm digital data (which runs at 128kbps) a run for its money! I suspect it is wider than the standard 25kHz FM channel, hence the need for a "specialised" dongle (okay, bog standard digital TV receiver dongle based around the infamous Realtek chipset). It might be that the discriminator output available via the 9600 baud packet radio jacks isn't up to the task… but even ¼ of this data rate would be a brilliant alternative to the Bell-203 modulation we're used to. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] DRM Mode H
On 02/02/17 11:44, David Ranch wrote: > > You can see working examples of this DRM mode in the SSTV programs for > Linux: > >Qsstv I thought QSSTV was analogue… it was last time I tried it. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] not much codec 2 data
On 20/09/16 08:26, glen english wrote: > He's is an experience to share... and all this I know already but when > you experience just how frugal codec2 is on speech bits, it is > enlightenment. > > I am doing a project that uses Codec2 and sends data over Si4460 > transceiver chips. > > one thing that has become apparent is there is not much data coming out... > > I send a packet every 20mS so that lost packets don't matter so much. > But.. all there is to transmit is ... 8 bytes ! :-) there is 12 bytes > wrapped around it. Ha ! > > which means the data rate (and BW) has to go up to cope with the > overhead. and David has worked so hard to get the bits down, and I > just throw 1.5x excess in radio overhead... One option might be to use some forward erasure coding on each Codec2 frame to give you two 8-byte packets, then in each RF frame, you send packet 2 (or zeros if it's the first packet) from the previous Codec2 frame concatenated with packet 1 from the current Codec2 frame. You double your data rate, but if an RF frame gets lost, you can still recover the full message with no delay or loss. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] cascaded ulaw, Alaw and,AMBE etc
On 17/09/16 18:28, glen english wrote: > Yeah. > > Cascading codecs is always trouble. > > BTW My understand of the word TRANSCODING is going between one encoded > method and another without going back all the way to uncompressed. Going > between different video encoding methods usually done by transcoding. > Most video encoding is all DCT / macroblock based so is probably more > relationship between codecs than speech codec variations > > > In this problematic voip case: uncoded PCM (microphone) >> AMBE2 >> > over air >> decoded >> PCM >> uLaw encode>> ulaw decode >> headset. (and > reverse) . Transcoding is going from one format to another, and when the destination is a lossy format, that will mean a reduction in quality. Decoding to uncompressed shouldn't incur loss compared with a hypothetical conversion from AMBE2 direct to µ-law, more likely the assumptions made by the µ-law CODEC don't hold true for the synthesized voice from the AMBE2 CODEC, and that would be why it sounds so terrible. Regards, -- 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
Re: [Freetel-codec2] codec2 / stm32/ readme .txt help required
On 24/03/16 16:04, Joel Stanley wrote: > On Thu, Jan 21, 2016 at 5:31 AM, Stuart Longland > wrote: >> The commit log on that project seems to suggest it is *very* far behind. > > Yeah. Since I moved house, the cron job that used to update the mirror > has not been running. I noticed this when Mark came around the other > day. > > I'll set it back up in The Cloud to reduce the likelihood of this > happening again. No biggie. As it happens I've had very little time for FreeDV stuff. Things were busy, then a colleague of mine was riding to work, lost control of his bicycle and crashed, dying from his injuries a fortnight later. (I believe, first fatality on the Go Between Bridge here in Brisbane.) So we've had to pick up his workload, and things have gotten busy during the week, with my weekends spent researching brain injury and looking in physics books with a view to improving things so the same accident does not happen again. I see lots has happened, and I do intend to return to FreeDV work. It's good to see the project moving ahead so fast. :-) Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Possible to have multiple Codec2 instances?
On 31/01/16 11:37, Stuart Longland wrote: >> BTW could you pls point me at some instructions for the current menu >> > system? I built the code last week but wasn't sure what to do next. > There's some notes in the place where I keep the binary builds. > https://stuartl.longlandclan.id.au/freedv/sm1000/ … and now they're in Subversion. https://svn.code.sf.net/p/freetel/code/codec2-dev/stm32/MENU.txt -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Possible to have multiple Codec2 instances?
On 31/01/16 05:11, David Rowe wrote: > Hello Stuart, > > If you include freedv_api_internal.h you will have access to freedv > states which include codec 2. > > Thinking about the use case I imagine a user with be either > manipulating menus OR running freedv. So perhaps it's OK to hijack the > codec 2 states (and the speaker driver) for the duration of the menu > session and you don't need to worry about mixing simultaneous audio? Ahh okay, so there's a way to get in via the back door as it were. The main area where the mixing takes place is when switching modes between Analogue, FreeDV 1600 and Tone mode, which is done by pressing the SELECT and BACK buttons momentarily. There's a short beep as an acknowledgement that you've hit the button, and an announcement is made after a second or so. This is because when navigating the menu, you'll likely be counting the beeps to keep track of where you are when navigating quickly, and the announcements after the short pause help prevent people from getting lost if they lose count. So if you think you might've hit that button one too many times from analogue mode, or accidentally hit BACK instead, you'd hear: dah-dadadah-dadit-dit → "TONE" instead of: didadadadah-dadidididit-dadadadadah-dadadadadah → "1600" or possibly: didah-dadit-didah → "ANA" Handy, because apart from that, "TONE" and "1600" are indistinguishable, as both receive a FreeDV signal and decode it, but only one transmits your voice (the other transmits a tone for testing purposes). In the future, I hope a "700B" mode will join them. As for sound mixing, it is possible that someone might be in analogue mode, hear a FreeDV transmission, hit SELECT, and straight away the FreeDV decoder starts processing. After a second, there'll be a situation where a voice prompt will attempt to play whilst a FreeDV transmission is received. I could opt to skip the voice transmission and/or revert to a morse transmission in that case. > BTW could you pls point me at some instructions for the current menu > system? I built the code last week but wasn't sure what to do next. There's some notes in the place where I keep the binary builds. https://stuartl.longlandclan.id.au/freedv/sm1000/ -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Another item for the PCB TO-DO List: nJRST pin
On 31/01/16 07:32, glen english wrote: > My practical experience (20+ designed) with the JRST pin is you should > leave it unconnected or pulled. Well, I only put the idea forward because when I did a search for what caused the error I was getting, there was mention of an erratum item regarding the STM32F4 in the post I linked to. The post seemed to describe the symptoms I was seeing. The fact that David's had success using the STM32F4 Discovery board as a SWD programmer to program SM1000 boards suggests something else might be the matter at my end. Probably the same reason I have trouble invoking the DFU bootloader. I would definitely agree that it should be pulled up to Vcc. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Possible to have multiple Codec2 instances?
On 30/01/16 20:42, David Rowe wrote: > I'd suggest you first try the code on an x86 - much more benign > platform. When that works, port to the SM1000. You want to avoid any > actually debugging on target - for reasons you are experiencing. > > I would suggest you do not create another instance of Codec 2 - suspect > that would make you run out of memory. Ahh okay, is it possible to share the instance that FreeDV uses? I didn't see an obvious way to do that and it didn't seem like a good idea. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
[Freetel-codec2] Possible to have multiple Codec2 instances?
Hi all, I've spent an afternoon on a wild goose chase trying to figure out what causes the SM1000 to keel over when I try to decode some Codec2 audio that I have in a const static C array. This is being done in the main SM1000 firmware, so basically I create in addition to the FreeDV decoder running in FreeDV 1600 mode, I also have my own instance of the Codec2 decoder for menu prompts. This is wrapped up in a speech state machine. Basically prompts to be spoken are broken out into "phrases" that are either silent pauses, sequences of digits or Codec2 recordings. Right now I'm just focussing on playing a single recording. My code is based on what I saw in c2dec. My first step currently is that I set the state machine up in Codec2 1300 mode. (I had it at 1600 initially, then tried 3200, I note the FreeDV 1600 mode uses Codec2 1300, so I've now switched to that.) http://git.longlandclan.id.au/?p=for-upstream/freedv/codec2.git;a=blob;f=stm32/src/sm1000_main.c;h=4fd5573ff236cfa7a84eced74f14afe075a68914;hb=speech-debug#l296 This is where I create the Codec2 decoder. http://git.longlandclan.id.au/?p=for-upstream/freedv/codec2.git;a=blob;f=stm32/src/speech.c;h=7d40d9028272e1132bbfad02ab00b56a981f7c1d;hb=speech-debug#l59 The idea is that this state machine operates asynchronously, when there's "phrases" to be played back, you can call speech_next on the state machine to get the next sample. Internally when it needs to decode a bit of audio, it fetches the next frame and feeds that to Codec2. http://git.longlandclan.id.au/?p=for-upstream/freedv/codec2.git;a=blob;f=stm32/src/speech.c;h=7d40d9028272e1132bbfad02ab00b56a981f7c1d;hb=speech-debug#l162 Now it's here that things turn pear shaped. In my current situation, speech_player->phrase_input_pos points to the first byte of a byte array containing a Codec2 audio sample. I'd expect that it would do its decoding, and plonk the samples in speech_player->samples_8k, which is a malloc'ed buffer for this purpose. As far as I know, it's big enough, I've tried doubling it and it hasn't made a difference. Instead of getting audio placed here, the SM1000 crashes. I've traced the crash all the way to lpc_post_filter so far, and still I'm none the wiser. So I'm lost. Is there something else that needs to be done with the Codec2 decoder before I try pumping it with data? Is there a limit to the number of instances that can be active (RAM permitting)? Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Another item for the PCB TO-DO List: nJRST pin
On 30/01/16 16:20, Stuart Longland wrote: > Some theories I'm thinking of: > - Switch bounce? Maybe I'm not doing it right and there's just a little > contact bounce as I'm holding it. > - RFI? Here at The Gap, I'm practically in the shadow of Mt. Coot-tha, > where there exists many high-power VHF and UHF transmitters for the > local television and radio stations. Okay, add another theory: - ambient temperature I'm working on the back deck where there's plenty of light, space, and there's the odd breeze to keep things cool. It got to 30.8°C today, and it's now 25.5°C. I'm able to bring it in and out of DFU mode reliably now, whereas before it would take between 2 and 10 attempts (seemingly random). It's like the little STM32 wants to taunt me. ;-) -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Another item for the PCB TO-DO List: nJRST pin
On 30/01/16 15:33, David Rowe wrote: > The link seems to refer to flashing via STLINK - the 3 pin debug connector. > > I have used STLINK to flash SM1000s many times during development - > using just the 3 pins on CN1. This include 405 and 407 devices. I used > a Discovery Board as the emulator "pod". Interesting, wonder what I'm doing wrong then. I'm using an actual STLink/V2 programmer device, which seems to work fine for actually debugging the SM1000, just not programming it. > I'm not familiar with the nJRST pin on the uC, can you pls describe > exactly what connection you would like to see (i.e. pin numbers, where > the net would be routed to)? My apologies, it's called nJTRST; pin 90. It otherwise is known as PB4. > We have provision for a reset button SW5 (nRST pin 14 on the uC) on the > SM1000 which I found handy during development when I was flashing via > STLINK. Ahh, wondered what that button did. Didn't seem to do anything though. > I have found DFU mode comes up immediately every time, by holding PTT > down as the SM1000 is switched on. I just tried again on a new SM1000 > and 5/5 times on first press. Perhaps you have a hardware fault? > Cables? Contact me off list if you think its the SM1000 hardware. Interesting, not sure what's going on then. The set-up here: - SM1000 has case open - STLink/V2 plugged into CN1 - my laptop (late 2008 Apple MacBook) plugged into "RIG SPKR" - an old pair of headphones (70's era paper cone ones) plugged into EXT SPKR - Power from 100Ah 12V AGM battery Some theories I'm thinking of: - Switch bounce? Maybe I'm not doing it right and there's just a little contact bounce as I'm holding it. - RFI? Here at The Gap, I'm practically in the shadow of Mt. Coot-tha, where there exists many high-power VHF and UHF transmitters for the local television and radio stations. Anyway, currently I've been attempting to get the speech prompts working. I note that the SM1000 here fails to pass through analogue or decode FreeDV 1600 since around revision 2482 (according to `git bisect`) and I'm just trying to figure out why. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
[Freetel-codec2] Another item for the PCB TO-DO List: nJRST pin
Hi all, Here's something we should add to the PCB for the next SM1000 revision, a pin for nJRST. https://sourceforge.net/p/openocd/mailman/message/32108017/ Presently, due to that erratum, the only way to flash a SM1000 is using dfu-util, and I'm finding that it might take as many as 5 or 10 attempts of power cycling and pressing PTT in to get it into DFU mode. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] codec2 / stm32/ readme .txt help required
On 21/01/16 04:53, Stuart Longland wrote: > On 20/01/16 16:16, arooj naz wrote: >> > Hi how are you . I am doing a project of voice encoding and decoding >> > using sm1000 board. Currently I donot have havdrware or any thing but >> > for my own practice i am following your codec2 >> > <https://github.com/freedv/codec2>/stm32 >> > <https://github.com/freedv/codec2/tree/master/stm32>/README.txt Just noticed this… worth pointing out that the official source for this is in Subversion on SourceForge. The git repositories are third-party and likely to be behind somewhat. The commit log on that project seems to suggest it is *very* far behind. Here's where you should be looking: http://sourceforge.net/p/freetel/code/HEAD/tree/ If you must use git, I have a mirror: http://git.longlandclan.id.au/?p=for-upstream/freedv/codec2.git -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] codec2 / stm32/ readme .txt help required
On 20/01/16 16:16, arooj naz wrote:
> Hi how are you . I am doing a project of voice encoding and decoding
> using sm1000 board. Currently I donot have havdrware or any thing but
> for my own practice i am following your codec2
> <https://github.com/freedv/codec2>/stm32
> <https://github.com/freedv/codec2/tree/master/stm32>/README.txt
> . Trying to resolve the following error in build codec 2 unit test
You seem to have forgotten the error message here.
> In Makefile: edit the BINPATH variable for your toolchain location
> edit PERIPHLIBVER for the current version of the peripheral
>library, currently V1.3.0
> delete power_ut.elf target from the all: target
Hmmm, seems those instructions need a minor update:
- there's no need to delete power_ut.elf from anything
- PERIPHLIBVER unfortunately keeps changing due to ST having the
unfortunate habit of not including a version number in the URL where the
peripheral library is kept. So you wind up downloading the "latest"
version, whose top-level directory changes with each version. Hence the
only way to know is to manually unzip the file you download and have a
look. The top-level directory will have _${PERIPHLIBVER} appended to
the name.
- BINPATH is now set in a file called 'local.mak' which you create. The
exact path depends on where you unpacked `arm-gcc`, in my case I placed
it under /opt/gcc-arm-... Alternatively, you can set CROSS_COMPILE
(which is the Linux kernel convention):
e.g.
PERIPHLIBVER=V1.6.0
CROSS_COMPILE=/opt/gcc-arm-none-eabi-4_7-2013q1/bin/arm-none-eabi-
PERIPHLIBVER=V1.6.0
BINPATH=/opt/gcc-arm-none-eabi-4_7-2013q1/bin
These two snippets are identical. If you look in the Makefile, any
variable set with ?= can be overridden in local.mak, or set as an
environment variable.
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] CHIP
On 09/01/16 10:08, Bruce Perens wrote: > There is also Raspberry Pi Zero, which is supposed to cost $5. Downside with the Pi Zero is zero audio hardware. You'd have to interface an I²S chip yourself. > If you want good battery life you will need to modify David's present > software to be interrupt-driven, to have some sort of hardware squelch > that interrupts when there's a signal to be handled, and to spend most > of its time halted. This is the conventional means of getting battery > efficiency. > > SM1000 currently busy-loops. This makes it run somewhat hotter and it > used more power than otherwise, but mostly nobody cares. The main > economy would come from hardware squelch. From what I've seen, the ADC/DAC drivers seem to operate using DMA and interrupts. That would seem to be most of where the real-time work is being done. I'm slowly moving more things to state machines so one could possibly determine when the CPU can be put to sleep from that. I think power-saving support is a long way off, and even without that, the SM1000 seems to sip power. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Debugging the SM1000. [was Re: Dumb SM1000 SWD question, where's pin 1?]
On 12/12/15 17:55, glen english wrote: > Stuart, get it the wrong way around and worst case is it won't work... Yeah, figured as much. However, would it then be "not working" because I wired the connections to the SM1000 wrong, or "not working" because I buggered up my JTAG break-out cable. There was a good chance of the latter, since I basically cannibalised my old serial AVR programmer for its pin header sockets. -- 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] Debugging the SM1000. [was Re: Dumb SM1000 SWD question, where's pin 1?]
On 12/12/15 16:46, Stuart Longland wrote: > On 12/12/15 16:38, Steve wrote: >> > looking at that photo, it's the one on the left. R19 trace sneaks >> > between the right and middle pins and goes down to the left pin. > Ahh, gotcha. Okay, I'll plug 'er in and see what I get. > > Hopefully not smoke signals. :-) Okay, took a bit of tinkering, but here's the full detail. You'll need a recent OpenOCD, likely not the one shipped as a binary in Debian/Ubuntu. I'm doing this on a Gentoo host, and use dev-embedded/openocd- which pulls source from their git repository. You'll also need a cable that exposes the SWD pins from the JTAG header. The three pins you need are: Pin 7: SWDIO Pin 8: GND Pin 9: SWCLK http://www.longlandclan.id.au/~stuartl/freedv/2015/12/12-swd/sm1000-stlinkv2-swd.jpg shows how to connect this cable. I've actually broken out the other three signals as well. SWDIO is the green wire, SWCLK is the blue wire, and the white/orange one is the ground. Also visible but not used is MCU VDD (orange, pin 1), TRACESWO (brown, pin 13) and nRST (white/green, pin 15). Open up two terminal sessions. In the first, create a file in your local working directory called openocd.cfg with the following content (thanks to Glen English for getting me started with the ST-Link/V2): source [find interface/stlink-v2.cfg] source [find target/stm32f4x.cfg] reset_config none separate That last line is important, since we don't connect nRST to the target on the SM1000. Then start openocd, you should see this: > RC=0 stuartl@vk4msl-mb /tmp $ openocd > Open On-Chip Debugger 0.10.0-dev-00120-g7a8915f (2015-11-25-18:49) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.org/doc/doxygen/bugs.html > Info : auto-selecting first available session transport "hla_swd". To > override use 'transport select '. > Info : The selected transport took over low-level target control. The results > might differ compared to plain JTAG/SWD > adapter speed: 2000 kHz > adapter_nsrst_delay: 100 > none separate > none separate > Info : Unable to match requested speed 2000 kHz, using 1800 kHz > Info : Unable to match requested speed 2000 kHz, using 1800 kHz > Info : clock speed 1800 kHz > Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748 > Info : using stlink api v2 > Info : Target voltage: 1.555905 > Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints > Info : accepting 'gdb' connection on tcp/ > Info : device id = 0x10016413 > Info : flash size = 1024kbytes > undefined debug reason 7 - target needs reset > stm32f4x.cpu: target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x0100 pc: 0x0802cdb0 msp: 0x2002 > Info : Unable to match requested speed 8000 kHz, using 4000 kHz > Info : Unable to match requested speed 8000 kHz, using 4000 kHz > adapter speed: 4000 kHz > Now flip over to your second session and run gdb: > RC=0 stuartl@vk4msl-mb ~ $ arm-none-eabi-gdb > projects/sm1000/codec2/stm32/sm1000.elf > GNU gdb (Gentoo 7.8 vanilla) 7.8 > Copyright (C) 2014 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "--host=x86_64-pc-linux-gnu > --target=arm-none-eabi". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://bugs.gentoo.org/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from projects/sm1000/codec2/stm32/sm1000.elf...done. Tell gdb to connect to the "remote" target: > (gdb) target remote localhost: > Remote debugging using localhost: > warning: Can not parse XML target description; XML support was disabled at > compile time > warning: Can not parse XML memory map; XML support was disabled at compile > time > 0x in ?? () At this point, you simply need to tell the device to reset and initialise: > (gdb) monitor reset init > stm32f4x.cpu: target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x0100 pc: 0x0802cdb0 msp: 0x2002 > Unable to match requested speed 8000 kHz, using 4000 kHz > Unable to match requested speed 8000 kHz, using 4000 kHz > adapter speed: 4000 kHz Now, set you
Re: [Freetel-codec2] Dumb SM1000 SWD question, where's pin 1?
On 12/12/15 16:38, Steve wrote: > looking at that photo, it's the one on the left. R19 trace sneaks > between the right and middle pins and goes down to the left pin. Ahh, gotcha. Okay, I'll plug 'er in and see what I get. Hopefully not smoke signals. :-) Regards, -- 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
Re: [Freetel-codec2] Dumb SM1000 SWD question, where's pin 1?
On 12/12/15 16:06, Steve wrote: > The one on the bottom goes to R19 and top goes to R20 looks like. I'm > looking at the PNG in the repository. > Bottom also shows a wider bar on the silkscreen. Bottom being with > silkscreen "power" to the left (nearest PTT). Well, now I'm confused. This is the schematic: http://www.longlandclan.id.au/~stuartl/freedv/2015/12/12-swd/sm1000-swd.png This is what I see: http://www.longlandclan.id.au/~stuartl/freedv/2015/12/12-swd/sm1000-swd.jpg The trace looked to be running from R19 to that top pin, I can see the thicker bar down the bottom end (sort-of visible in that photo), but I'm not sure if that's accidental or if that's indeed the convention being used. I'm used to numbers or a little arrow on the silkscreen. That might be worthwhile on the next run of SM1000s. :-) Regards, -- 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] Dumb SM1000 SWD question, where's pin 1?
Hi all, It's a rainy day here in Brisbane, just perfect weather to experiment with the SM1000, maybe get some voice announcement code happening. I figured I'd get my shiny ST-Link/V2 dongle working so I can single-step and debug the code. I'm looking at the board, I see there's a 3-pin header for SWD: CN1. There's nothing I can see though that marks which of those pins is pin 1 (aka SWCLK). The only hint I have is R19 connects to it; I can see a trace from R19 going to the pin closest to the SELECT/BACK buttons. Am I on the right track to assume that's SWCLK and that the other end is SWDIO? Regards, -- 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
Re: [Freetel-codec2] SM1000 and the FreeDV 700B mode
On 22/11/15 08:17, glen english wrote: > Stuart, SM1000 has the SWD pins (2 signals) exposed, doesn't it ? > > use that. I would, but I don't have anything (yet) that will plug into SWD pins. Only a Olimex JTag dongle. This is something I hope Mouser will help me with later this week. -- 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
Re: [Freetel-codec2] SM1000 and the FreeDV 700B mode
On 25/10/15 10:44, Stuart Longland wrote: >> 2/ FB on taking a look at 700B mode. I described some suggested first >> > steps on an email to the list on 24 Sep. Happy to work with you based >> > on the results of these unit tests. I imagine I'll be up for some modem >> > memory/CPU optimisation. > Yep, I did see that. I'm looking around for a suitable debugger board, > as it's impossible to see what's going on right now. All I have is some > STM32F103 boards (Cortex M3; 64kB RAM, 512kB flash, no FPU) and the > SM1000 which has no JTAG exposed. > > The STLink/V2 programmer cables are not expensive and OpenOCD supports > them. Might be time to let some moths out of the wallet. ;-) Well, I've just done that. On order is a STM32F4-Discovery board (I was tossing up between it and the STM32F411 board), a STLink/V2 (I know the discovery board has one too) and a Lattice iCE40HX-8K FPGA break-out board. That should be sufficient to let me "peer in" to what the SM1000 is up to, as well as facilitating a bit more experimentation. -- 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
Re: [Freetel-codec2] Encrypting GSM Phone
On 13/11/15 15:33, David Rowe wrote: > The SM1000 drivers for the various audio ports already work in full > duplex. However there may be a CPU load issue to run full duplex, in > which case further code optimisation would be required. Indeed, I tried full-duplex audio on the SM1000, seeing if I could take the microphone audio input and feed that back to a headset to give me an eyes-free indication that the PTT was on, but couldn't find a way to collect samples and do the software mixing in an acceptable manner. By far though, the biggest challenge will be cramming 1600bps audio down a GSM voice CODEC. The human ear cannot detect phase, and is poor at detecting amplitude and frequency. Add to this the fact a voice CODEC is attempting to simulate the human voice and how well humans typically can "whistle" modem tones (that is, not well), it is little surprise that trying to do data comms over this link is proving to be a major challenge. 1200bps is *really* pushing it. 700bps will be easier, however last time I tried FreeDV 700bps, the SM1000 crapped itself when I switched to DV mode. (And yes, it's time I pulled my finger out and did some more on the SM1000.) -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] SM1000 and the FreeDV 700B mode
Hi David, On 25/10/15 11:39, David Rowe wrote: > Re debugger suggest a $20 STM32F4 Discovery. It has a debugger uC and a > STM32F4 on board. Standalone (without the SM1000) it can run STM32F4 > unit tests, using stdio.h functions to/from a Host PC (semi-hosting) > > You can then move a few jumpers and attach it to the SM1000 as a ST-LINK > debugger/flasher, see SM1000 page "Testing and Debugging" section for links. Yes, this is an option too. Neither is a particularly expensive option. > However TBH I avoid any actual "debugging" with gdb on the STM32F4. I > get the modules working on a PC first then run unit tests on the STM32F4 > using semi-hosting to track down any differences. Yeah, in the case of tracking down FreeDV 700B though, it might be useful to single-step it until things go pear shaped, although after stumbling on some #ifdef's, I have an idea what might be going on. In the meantime, I'm starting to get together some speech playback goodness. The first step is figuring out how to represent the phrases, so that our voice-over person doesn't have to record separate recordings for every permutation of setting and value. This is being done in a branch for now. http://git.longlandclan.id.au/?p=for-upstream/freedv/codec2.git;a=commit;h=61287ddb5a5e421e3a9b2da49aba7cfba102d2e5 The thought is, the phrases will be simple structs that either encode a length of silence, a run of digits/letters, or point to a Codec2 recording. When I've deduced a recording, I track the frame number, feeding the decoder with frames and upsampling the samples at the other end. Hopefully it won't hurt the CPU too much. Regards, -- 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
Re: [Freetel-codec2] SM1000 and the FreeDV 700B mode
On 25/10/15 10:49, Steve wrote: > Added to the language in C99 if I remember right... No problem in GCC. Ahh, figured it was a newer feature. I sometimes have to deal with K&R C. -- 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
Re: [Freetel-codec2] SM1000 and the FreeDV 700B mode
Hi David, On 25/10/15 10:27, David Rowe wrote: > 1/ Nice work on the UI improvements. I'd be happy to work with you on > an option where we can use compressed speech prompts (my morse is rusty!). Yep, that would definitely be worth doing. Having gotten the time-out timer working, I'll probably have to put this aside for a bit and go get some chores done for the week. Then I might start looking at what's needed since that would be the next easiest option. > 2/ FB on taking a look at 700B mode. I described some suggested first > steps on an email to the list on 24 Sep. Happy to work with you based > on the results of these unit tests. I imagine I'll be up for some modem > memory/CPU optimisation. Yep, I did see that. I'm looking around for a suitable debugger board, as it's impossible to see what's going on right now. All I have is some STM32F103 boards (Cortex M3; 64kB RAM, 512kB flash, no FPU) and the SM1000 which has no JTAG exposed. The STLink/V2 programmer cables are not expensive and OpenOCD supports them. Might be time to let some moths out of the wallet. ;-) Regards, -- 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
Re: [Freetel-codec2] SM1000 and the FreeDV 700B mode
On 25/10/15 10:01, Stuart Longland wrote: >> > /* Set up FreeDV modem */ >> > f = freedv_open(FREEDV_MODE_700B); Hmm, and even just having it do 700B alone, more to it is needed than just this. Changing 1600 to 700B causes the SM1000 to crap itself when going into DV receive mode. -- 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] SM1000 and the FreeDV 700B mode
Hi all, I'm now starting to look at the 700B mode, since that would be the next major advance for the SM1000. (All the little stuff that can be practically achieved has been achieved.) I put this off until I got a better understanding of how the code worked. As I understand it, the structures for FreeDV are allocated on the heap using malloc, and that to switch modes, I must first free the existing instance and open a new one. > /* Set up FreeDV modem */ > f = freedv_open(FREEDV_MODE_700B); > n_samples = freedv_get_n_speech_samples(f); > n_samples_16k = 2*n_samples; > > short adc16k[FDMDV_OS_TAPS_16K+n_samples_16k]; > short dac16k[n_samples_16k]; > short adc8k[n_samples]; > short dac8k[FDMDV_OS_TAPS_8K+n_samples]; The n_samples bit concerns me though. That basically decides the size of the buffers used in encoding/decoding. Interestingly, we seem to be passing an integer non-const variable in the declaration of these arrays; didn't think that was allowed. (It clearly is here, then again, I've seen some like the TI Code Composer compiler which would definitely reject that bit of code.) These arrays get declared on the stack, so are going to be hard to change. We can pretend they are smaller, but not bigger. To my way of thinking, we have a couple of options: 1. We can use malloc/free to allocate these on the heap, which means we can re-allocate them later. 2. We can pick a size that will be big enough for both 700B and 1600, and leave them fixed at that size. 3. We allocate two sets of buffers, one for 700B, the other for 1600. Option 3 seems unwieldy in terms of code footprint and memory usage, so probably not worth considering. Option 2 would be the simplest, but I have no idea how big n_samples is, or how much it changes. Option 1 wouldn't be too hard, but I'm not sure what the implementation of malloc/free permits. Some embedded versions have funny restrictions like requiring you to free objects in the reverse order to their allocations. Some don't actually implement free(). Then there's the game of dealing with memory fragmentation. Each of those could bite us in unexpected ways. The other option is we just forgo giving the user a choice at run-time. The device stores the 700B/1600 mode selection in its configuration settings, and to change it requires a power-cycle to reboot. What's actually needed in order to switch from one mode to the other? -- 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] SM1000 has a time-out timer
Hi all, After a few weeks hiatus due to other events (in particular, the Brisbane-to-Gold-Coast bicycle ride), I've finally gotten back to the SM1000 and have finished my implementation of a time-out timer. http://stuartl.longlandclan.id.au/freedv/sm1000/ This is another menu item between UI and MODE, by default the time-out timer period is 0 seconds (disabled), but you can adjust it between 0 and 600 seconds (0-10 minutes) in steps of 5 seconds. I might look into some non-linear adjustment since beyond 1 minute bigger steps would be helpful. The time-out timer has a warning period which is also configurable in steps of 5 seconds. It starts counting down N seconds before the time-out, where N is configured under the "WARN" menu item. During the warning period, a beep is heard each second, and the PTT LED flashes. On time-out, a tune is played and the unit goes into receive mode as if the PTT had been released. -- 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
Re: [Freetel-codec2] Email to ST regarding use of their application notes.
On 29/09/15 03:39, Bruce Perens wrote: > Oh, I see it's LGPL. That's fine. > > On Mon, Sep 28, 2015 at 10:37 AM, Bruce Perens <mailto:br...@perens.com>> wrote: > > Good work! How would you like to license it? Yep, I figured LGPL was the safest option. I suppose I could have also gone 2-clause BSD or MIT. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Email to ST regarding use of their application notes.
Hi Bruce, On 28/09/15 15:41, Bruce Perens wrote: > In general it's difficult to reach the people who understand copyrights > and licensing in a company like ST. This looks like it's following a > lawyer's directions regarding liability but with zero understanding of > copyright. > > The most important thing you need to know: if you are only using > knowledge that you are reading in a book, you can do what you want as > long as you do not copy and paste directly from that book. Schematics, > data structures, register definitions, function names, argument lists > and the types used theirin, and lists of facts are not copyrightable. > They may be covered by patents, but we get to use the patent if we buy > the chip. The applicable law in the U.S. is 17 CFR 102(b), there are > similar laws in most nations. > > If there is a firmware file that you have to use, which is not licensed > appropriately, copyright does apply to that. If you can't get > appropriate licensing, write it out. > > If it gets to the point that we need a lawyer, we have John Ackermann. I appreciate the clarification. As it happens while I was waiting from an answer from ST, I sat down and (without looking at ST's code) implemented it myself. The details are covered here: http://stuartl.longlandclan.id.au/blog/2015/09/27/implementing-eeprom-emulation-on-the-sm1000/ I had looked at the application note PDF, and I have a copy of the application note sources which I unzipped, but have not yet tried compiling or inspected. I basically saw the notice in the Release Notes and stopped there. The PDF however, looks fairly generic. So apart from making calls to the flash routines in the peripheral library, the actual virtual EEPROM algorithm is my own design. Theirs probably has fewer bugs, but ours is under a license we want. Ours is also a lot more capable in that we can store arbitrary structures. The inspiration was more akin to UBI from the Linux kernel. I'm no lawyer, but I feel from a legal stand point, this is probably the safer option. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] SM1000: Persistent settings now working
Hi Mel, On 28/09/15 07:01, Mel Whitten wrote: > Stuart, > > Just had a long QSO (1320KM) with N4DV using the SM1000 and your 923 "CW" > annoucement version. It works fantastic. I like CW. :-) The radio was an > old ICOM 706Mk2 running about 25 watts/vert ant. Gerry said the audio was > excellent and could NOT tell the difference between my Flex and the old > ICOM. Yes, we were having decent prop and the QRM was low (never dropped a > word) but it does show that RX filtering and TX passband flatness may not > be required for Freedv to perform well. My microphone is a discontinued > Radio Shack "pc" mic. My Mic on the Flex is a $300 studio mic. :-) Not > every electret will work, but the right one can be perfect. > > ..and now in QSO with the east coast, AA3GZ and this one will be a marthon > QSO. :-) Good to know I haven't buggered up something else in my quest to add features. I suppose so long as the microphone and radio are above some minimum standard, more expensive is not necessarily better. The cost/effectiveness curve is rarely a linear one, this seems especially true for FreeDV. The headset I plan to use uses the speakers from a busted dual-side Heil Traveler and a microphone scavenged out of a mobile phone hands-free kit with a small length of hard drawn copper as the boom sheathed in a bit of off-cut plastic insulation from a length of 6-core alarm cable. The electret capsule is encased with a small plastic bag with a capacitor across it, heatshrink over the end where the wires come out, and a foam windsock over the end. A bit of velcro holds the old ear cups firmly inside my open-face motorcycle helmet, and I just ram the microphone in a space between the helmet lining and the shell. The whole lot, helmet included, cost me <$100. I find I get lots of comments about the clarity of audio. It has lasted through several storms without incident (getting that waterproofing right was key), and I find I'm still able to hear traffic just fine. (That said, in busy traffic, I turn the radio down or off.) A heads-up for all regarding flash: I have found one flash-related bug since patched in revision 2406: I had the sector size set at 64kB, which would eventually bite us when all 3 16kB sectors of flash had been written to as it'd start messing with code. (i.e. the device would eventually semi-brick itself and need to have the FreeDV firmware re-loaded via USB) Revision 2406 corrects the size of the sector in the code. Flash storage in general of course needs further testing, but so far, I haven't seen any issues. It seems to be doing exactly what I intended it to (for me anyway), although I should probably do some further testing just to make sure. (maybe emulate the flash using a file.) I might re-visit the block size, currently we're using 256-byte blocks to hold 16-byte configuration structures. 64 or 32 bytes would probably more than suffice unless we start doing clever things like storing parameters for voice recognition or offer automatic keyers. In the meantime, one might be able to "back up" settings by using `dfu-util`; I was able to dump the content of the configuration block, there are examples of the command I used on this list. It may be possible to re-flash that portion of flash with a preconfigured block, or to manipulate the image to include it. If the block size changes, I'll let you know. Long term, I think the plan should be to get CDC-ACM serial console working, then that can be used to back up settings, possibly using a TAPR TNC2-like interface. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] SM1000: Persistent settings now working
Hi, On 28/09/15 06:48, Walter Holmes wrote: > Does this only work for the sub menus? And not the primary modes at this > point? The shortcuts change the mode you're in *now*, so you can move between the different modes without changing the boot-up mode by just hitting the SELECT and BACK buttons. > Ie.. I was trying to save a persistent setting of powering up in the 1600 > FreeDV mode, instead of ANA mode. But the Long back, just returns back to the > Analog mode. The boot-up mode is chosen by the MODE sub-menu. Hold SELECT to enter the menu, it should announce "MODE", hold SELECT again to enter the mode menu, use SELECT/BACK to choose the desired boot mode (in your case, hit SELECT once to select "1600"), then hold SELECT to confirm (this puts you back in the root menu), then hold BACK to exit the root menu. Your device should now default to "1600" on power up. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] SM1000: Persistent settings now working
Hi Walter, On 28/09/15 00:27, Walter Holmes wrote: > So how does the persistent settings work? > > Does it just automatically save your last settings as you change them? > > I have been using your last updates quite successfully with a couple others > here in the States. > > I really appreciate all your great efforts on these. It's a wonderful thing > to see so much activity on enhancing the FreeDV world. > > And those of us that use the SM1000 mobile, it's especially nice to have the > feedback from the different modes since while driving since I'm not looking > at the LEDs. :) It stores the settings in RAM as you change. If you change a setting (and hold down SELECT to confirm it), it sets a flag internally that says "Things have changed, I need to save this". When you leave the menu (using the BACK button; not via PTT) it then looks for this flag, and if found, does the save then. So if you enter a menu, forget where you were, and hit PTT, it exits the entire without saving to flash. If you enter a menu, don't change anything, and then exit (using the BACK button), it'll leave the flash unchanged (to prevent wearing it out). Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] SM1000: Persistent settings now working
On 27/09/15 12:53, Stuart Longland wrote: > Another option just occurred to me. My previous scheme would basically > see 3 flash blocks get consumed: one "obsolete" block for the old > configuration, one new block with the new configuration, and a new copy > of what was in the old block. > > An alternative: store a serial as part of the ROM image. We load both, > and go for the image with the highest-numbered (after roll-over > correction) serial. When we store, we save over the older one, > incrementing our serial number by one. > > The serial can be a uint64_t to make roll-over pretty much "not going to > happen". Okay, I've just implemented this (revision 2405): > 10 27 00 00 00 00 00 00 fe ff fe ff ff ff ff ff |.'..| > 0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || > * > 0100 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 || > 0110 20 03 3c 02 01 00 00 00 ff ff ff ff ff ff ff ff | .<.| > 0120 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || > * > 0200 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 || > 0210 20 03 3c 04 01 00 00 00 ff ff ff ff ff ff ff ff | .<.| > 0220 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || > * > 0300 2a ec 66 4c 01 00 10 ff 03 00 00 00 00 00 00 00 |*.fL| > 0310 20 03 50 04 01 00 00 00 ff ff ff ff ff ff ff ff | .P.| > 0320 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || > * > 0400 a8 82 d9 64 00 00 10 ff 04 00 00 00 00 00 00 00 |...d| > 0410 e8 03 50 04 01 00 00 00 ff ff ff ff ff ff ff ff |..P.| > 0420 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || > * > c000 You can see a few things here. Address 0 is the index block for that sector. The other two sectors are unformatted for now, the next one will get formatted when the first one fills up. 10 27 00 00 is the erase cycle count in little-endian (1 in decimal). After that we've got the block flags. The first two blocks have been marked "obsolete", so the flags for those are set to zeros. The next two have a flags settings of 0xfffe: indicating they are in use (but valid). There's space for more flags as we need them. Skip down to offset 0x0100: the first 8 bytes have been zeroed out, meaning the block is obsolete. This is an old image, and the actual data starts at offset 0x0108. The 01 00 00 00 00 00 00 00 is configuration serial #1. 0x0200 is the same story. 0x0300 is the previous copy, serial# 3. You'll note the checksum in the first 4 bytes is present. Following on from that is the ROM ID (#1), block index, size of data in block, and a reserved byte (0xff). The block index is used for images that are larger than 244 bytes. The image is split into separate blocks, and this gives their order. When you do a read at X bytes into an image, it does a divide by 244 to get the block number, and uses the modulo of 244 to know how far into the block to start reading. 0x0400 holds the present copy, ROM ID 0. If I now change a setting on the SM1000: > 10 27 00 00 00 00 00 00 00 00 fe ff fe ff ff ff |.'..| > 0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || > … > 0300 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 || > 0310 20 03 50 04 01 00 00 00 ff ff ff ff ff ff ff ff | .P.| > 0320 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || > * > 0400 a8 82 d9 64 00 00 10 ff 04 00 00 00 00 00 00 00 |...d| > 0410 e8 03 50 04 01 00 00 00 ff ff ff ff ff ff ff ff |..P.| > 0420 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || > * > 0500 e7 96 31 53 01 00 10 ff 05 00 00 00 00 00 00 00 |..1S| > 0510 e8 03 3c 04 01 00 00 00 ff ff ff ff ff ff ff ff |..<.| > 0520 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |....| > * > c000 … we see now the old image at 0x0300 is now "obsolete", and the first block of ROM ID 1 is now held at 0x0500. Hopefully that should do the trick for us. -- 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
Re: [Freetel-codec2] SM1000: Persistent settings now working
On 27/09/15 13:44, glen english wrote: > FRAM is the solution. > Cypress > FM24CL16B, DKPN 428-3310-1-ND > > or a backup CR2032 battery STM32F4 has this built in, Pin 6 on the LQFP100/LQFP144 STM32F4 packages is VBATT, which keeps alive some 4kB of SRAM as well as the RTC. Hooking that to a supercapacitor or header for a small lithium battery would be all that's needed. -- 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
Re: [Freetel-codec2] SM1000: Persistent settings now working
On 27/09/15 13:38, Steve wrote: > My neighbor had a stereo preamp that had digital controls, and it > powered up from the last settings. After 10 years it only powered up > from factory settings. I told him his EEPROM probably used up its > number of writes. Have a guess what Subversion r2401 fixes. :-) That said, an alleged write endurance of 10k cycles, and we're using 48kB (3 16kB sectors) of it 256-bytes at a time: our 256 byte "EEPROM" has a write endurance of: 16kB sector / 256 byte block = 64 blocks, minus one for sector header = 63 blocks. Times 3 sectors, that's 189 blocks that have to each be re-written 1 times before the sectors are depleted. -- 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
Re: [Freetel-codec2] SM1000: Persistent settings now working
On 27/09/15 11:29, glen english wrote: > Well the other thing is, it's not that mission critical is it ! Maybe I > am going overboard (usual). > I am used to my boxes being in orbit or out of helicopter access > mountains and so losing its marbles is not an option ! Yes, we're coding a little modem that's going to be in all probability sitting in someone's shack. It isn't New Horizons. That said, it's probably healthy we are considering such things. Another option just occurred to me. My previous scheme would basically see 3 flash blocks get consumed: one "obsolete" block for the old configuration, one new block with the new configuration, and a new copy of what was in the old block. An alternative: store a serial as part of the ROM image. We load both, and go for the image with the highest-numbered (after roll-over correction) serial. When we store, we save over the older one, incrementing our serial number by one. The serial can be a uint64_t to make roll-over pretty much "not going to happen". I suppose a "nice to have" would have been a supercap to keep Vbatt charged up on the STM32F4, then the few kB of static RAM could be kept active and be used to store runtime state. But, it doesn't, and so no use wishing it did. We make do instead. :-) -- 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
Re: [Freetel-codec2] SM1000: Persistent settings now working
On 27/09/15 11:13, glen english wrote: > another thing to consider doing stuart is having TWO copies > > so if it got turned off during a write, it doesnt trash anything > > - have two copies of the same structure, and have CRCs for each of the > structures. > > When you begin writing to one, set the struct DIRTY before writing > then update that struct, write the crc and then set clean. > > then do the other struct (probably in a different sector) . > > when the system wakes up, it can read the structures. a trashed one can > be re written (fixed) from the surviving struct. If they are both bad > crc or dirty, then obvious you need to start from defaults Yeah, that is an option. I can keep a "last good version" as a separate ROM image. The way the data is stored is more like a very crude filesystem. A filesystem with 224-byte blocks, 'ROM IDs' rather than names, and no other metadata. The 'ROM ID' is an 8-bit number that identifies the images within the space. We can store the previous configuration in a separate ROM. A possible implementation would be to read the current configuration in, copy that to a new ROM, then overwrite the old one with the new settings. That way, we lose nothing. If a write fails, we either have failed to write a copy of the old configuration, in which case the present one is still preserved, or we've failed to write the new configuration, in which case the boot up code can look for the old one. -- 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
Re: [Freetel-codec2] SM1000: Persistent settings now working
On 27/09/15 00:07, Stuart Longland wrote: > There is a somewhat buggy firmware image here: > http://stuartl.longlandclan.id.au/freedv/sm1000/sm1000-r2396.bin I've done some bug fixes: http://stuartl.longlandclan.id.au/freedv/sm1000/sm1000-r2402.bin This actually has working CRC32 calculation, and I haven't heard the hanging-note bug that was an issue in the previous release. -- 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
Re: [Freetel-codec2] Beginnings of virtual EEPROM support
On 27/09/15 07:24, Brady O'Brien wrote: > It may be worth adding __attribute__((packed)) to the in-flash structs > to ensure GCC doesn't add any padding. Yep, will do. For now it's nice just having *anything* remembered in flash. Probably this is more critical on the block headers. > The data sheet has 10k cycles as the endurance, with some flash > parameters measured after 100k cycles. 10 years retention at 105C, 30 > at 55C. Thanks. I did look, and I saw the 100k cycles, but didn't see the 10k cycles until much later. It's a big document, and typing /erase and hitting F3 repeatedly didn't make it jump out at me. ;-) At present, the data is so small, less than the 244-byte block payload, that it'll be a long time before we hit it. My development on this unit is likely to cost more in erase cycles. -- 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] SM1000: Persistent settings now working
Hi all, I've just managed to get the SM1000 to store settings using its internal flash. This includes things like having a preferred start-up mode so the unit can default to running in FreeDV 1600 for example. There is a factory reset procedure: hold down BACK while powering on. It'll beep for one second and flash the SYNC LED. Let go and it'll boot up normally. There is a somewhat buggy firmware image here: http://stuartl.longlandclan.id.au/freedv/sm1000/sm1000-r2396.bin I'm aware of a bug where the tones get "stuck" for a bit, I'll try to sort that out later, not at this hour of the night. -- 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] Beginnings of virtual EEPROM support
Hi all, Well, I'm getting it to store something in EEPROM, but not successfully retrieving it yet. This is my own creation rather than ST's. I've told the linker to set aside the region of flash between 0x08004000 and 0x0801. This gives us 3 16kB sectors of flash to play with, should be heaps. I've attempted some wear levelling and checksumming in this too. It is, in short, a very crude file system, capable of 256 "ROM files", identified by a numeric ID, and of arbitrary length. It is somewhat inspired by UBI. After flashing, this is what the content looks like: > RC=0 stuartl@vk4msl-mb ~/projects/sm1000/codec2/stm32 $ rm > sm1000-tmp.bin;sudo dfu-util -d 0483:df11 -c 1 -i 0 -a 0 -s 0x08004000:49152 > -U sm1000-tmp.bin > rm: remove write-protected regular file ‘sm1000-tmp.bin’? y > dfu-util 0.7 > > Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc. > Copyright 2010-2012 Tormod Volden and Stefan Schmidt > This program is Free Software and has ABSOLUTELY NO WARRANTY > Please report bugs to dfu-u...@lists.gnumonks.org > > Filter on vendor = 0x0483 product = 0xdf11 > Opening DFU capable USB device... ID 0483:df11 > Run-time device DFU version 011a > Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=0, name="@Internal Flash > /0x0800/04*016Kg,01*064Kg,07*128Kg" > Claiming USB DFU Interface... > Setting Alternate Setting #0 ... > Determining device status: state = dfuERROR, status = 10 > dfuERROR, clearing status > Determining device status: state = dfuIDLE, status = 0 > dfuIDLE, continuing > DFU mode device DFU version 011a > Device returned transfer size 2048 > DfuSe interface name: "Internal Flash " > bytes_per_hash=2048 > Starting upload: [###] finished! > RC=0 stuartl@vk4msl-mb ~/projects/sm1000/codec2/stm32 $ hexdump -x > sm1000-tmp.bin > 000 > * > 000c000 If I enter the menu, then exit (I'll have to set a flag somewhere that indicates a save is pending), I get this: > RC=0 stuartl@vk4msl-mb ~/projects/sm1000/codec2/stm32 $ rm > sm1000-tmp.bin;sudo dfu-util -d 0483:df11 -c 1 -i 0 -a 0 -s 0x08004000:49152 > -U sm1000-tmp.bin > rm: remove write-protected regular file ‘sm1000-tmp.bin’? y > dfu-util 0.7 > > Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc. > Copyright 2010-2012 Tormod Volden and Stefan Schmidt > This program is Free Software and has ABSOLUTELY NO WARRANTY > Please report bugs to dfu-u...@lists.gnumonks.org > > Filter on vendor = 0x0483 product = 0xdf11 > Opening DFU capable USB device... ID 0483:df11 > Run-time device DFU version 011a > Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=0, name="@Internal Flash > /0x0800/04*016Kg,01*064Kg,07*128Kg" > Claiming USB DFU Interface... > Setting Alternate Setting #0 ... > Determining device status: state = dfuERROR, status = 10 > dfuERROR, clearing status > Determining device status: state = dfuIDLE, status = 0 > dfuIDLE, continuing > DFU mode device DFU version 011a > Device returned transfer size 2048 > DfuSe interface name: "Internal Flash " > bytes_per_hash=2048 > Starting upload: [###] finished! > RC=0 stuartl@vk4msl-mb ~/projects/sm1000/codec2/stm32 $ hexdump -x > sm1000-tmp.bin > 00086a00001 > 010 > * > 000c000 The blocks are 256 bytes in size. The first block of each sector is the index block, and it marks what state each block in the sector is in. It also counts down the number of remaining erase counts. I'm not sure what the actual cycle limit is on these flash devices, I've guessed 10 program/erase cycles. 0x000186a0 == 10. So that bit works. ;-) The remaining blocks have a header with the following content: - 32-bit CRC (this is done by the hardware CRC module) - 8-bit ROM ID - 8-bit block index - 8-bit block size - 8-bits reserved. When a write is performed, the data is split into 256-8=248 byte blocks, and written to available blocks across the 3 sectors. When a block is to be changed, it zeros out the header fields and the block flags in the index, then writes a new copy of the block at a new location in flash. If a sector fills up completely with obsolete blocks, the sector is reformatted. 'Least that's how it's *supposed* to work. I guess I'll need to play around a bit more and figure out what's wrong with the algorithm. -- 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] Email to ST regarding use of their application notes.
Just a heads up. I'm currently investigating the possibility of emulated-EEPROM storage on the SM1000. ST have an Application note on this, however their "license" is vague. I have submitted the following question to them asking for clarification: > Hi, > > I'm looking to implement the EEPROM emulation mentioned in Application Note > AN3969 for an open-source project, specifically this device: > http://www.rowetel.com/blog/?page_id=3902 > > The firmware is publicly released under the Lesser GNU General Public License > v2.1: > https://sourceforge.net/p/freetel/code/2382/tree/codec2-dev/stm32/ > > The "license" states (confusingly under a heading called "license"): > The enclosed firmware and all the related documentation are not covered > by a License Agreement, if you need such License you can contact your > local STMicroelectronics office. > > THE PRESENT FIRMWARE WHICH IS FOR GUIDANCE ONLY AIMS AT PROVIDING > CUSTOMERS WITH CODING INFORMATION REGARDING THEIR PRODUCTS IN ORDER FOR > THEM TO SAVE TIME. AS A RESULT, STMICROELECTRONICS SHALL NOT BE HELD > LIABLE FOR ANY DIRECT, INDIRECT OR CONSEQUENTIAL DAMAGES WITH RESPECT > TO ANY CLAIMS ARISING FROM THE CONTENT OF SUCH FIRMWARE AND/OR THE USE > MADE BY CUSTOMERS OF THE CODING INFORMATION CONTAINED HEREIN IN > CONNECTION WITH THEIR PRODUCTS. > > What does "not covered by a license agreement" mean? I can understand the > bit about not being held liable, that is understood. I understand the bit > about guidance being the intended purpose. > > The language "not covered by a license agreement" sounds awfully like it's > "public domain", however I doubt this. > > What, exactly, am I permitted to do with the said software? > > The "license" agreement doesn't even say whether I'm even permitted to look > at the .c / .h files, let alone compile them. On this, the "not a license" > is rather vague. > > Am I permitted to embed it in a derivative work, such as the aforementioned > LGPLed firmware? Apart from accepting all responsibility for "direct, > indirect or consequential damages", what are our obligations in using this > example code in a publicly released open-source project? > > Regards, > Stuart Longland I dare say some will say just go ahead, and I plan to work on this as an easily deletable branch that will live in git for now. Once I get an answer either way from ST themselves, I'll either merge it into Subversion or drop the branch. -- 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
Re: [Freetel-codec2] SM1000 Menu-driven firmware
Hi all, On 23/09/15 20:27, Stuart Longland wrote: > So, without further ado, I've rebased off Subversion HEAD of the codec2 > repository, and I now have a *working* firmware image. Adventurous > people can try it out here: > > http://stuartl.longlandclan.id.au/freedv/sm1000/2015-09-23/ Thanks to David for providing Subversion access, these are now in the Subversion tree. Hopefully I didn't break anything. :-) Whilst I was here I fixed up the mix of MS-DOS and Unix text files, I've found that if the files in a repository all confirm to one standard, local Subversion clients tend to convert to what is native to the local system, and so `diff` and `patch` work as expected. When there's a mix, it gets confused and thinks they're binary, so patch-generation can get confused. Hopefully this doesn't mess up someone's working tree too much. I mention the commands I used to generate those, so it should be possible to replicate those same changes in a working tree to compensate. Probably first on my agenda this weekend will be to look at some sort of persistent storage. There's an application note from ST¹ that covers this. That should let people define things like what mode they want the SM1000 to boot into. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. 1. http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00036065.pdf -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] SM1000 Menu-driven firmware
On 24/09/15 02:07, Steve wrote: > I finally found the change, way down. When you delete the file and > upload a new one, I guess it doesn't go in as a diff. It says every > line has changed instead of just one. That's because it's a diff of a MS-DOS file vs a Unix one. So every line has had a \r removed. The repository had a mix, which probably confused diff/subversion/git. So what you're seeing is a combination of these: - http://stuartl.longlandclan.id.au/freedv/sm1000/2015-09-23/00-whitespace-cleanup/0001-Clean-up-line-endings.patch - http://stuartl.longlandclan.id.au/freedv/sm1000/2015-09-23/00-whitespace-cleanup/0002-Clean-up-trailing-whitespace.patch - http://stuartl.longlandclan.id.au/freedv/sm1000/2015-09-23/01-compile-fix-r2316/0001-sm1000_main-API-change-in-rev-2316.patch -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
[Freetel-codec2] SM1000 Menu-driven firmware
Hi all, I've just managed to fix up FreeDV 1600 support in my patchset, turns out some files in the firmware really need to be built -O3, not -O0 as is default, Oops! So, without further ado, I've rebased off Subversion HEAD of the codec2 repository, and I now have a *working* firmware image. Adventurous people can try it out here: http://stuartl.longlandclan.id.au/freedv/sm1000/2015-09-23/ Those looking for a git repository, I've thrown the lot up here: http://git.longlandclan.yi.org/?p=for-upstream/freedv/codec2.git The individual patch sets are separate branches. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Testing the SM1000 firmware
Hi Mark, On 20/09/15 10:53, Mark Jessop wrote: > You could also try this > file: https://www.dropbox.com/s/p52vjtgv1kw4k9e/vk100anzac_cq_1600.wav?dl=0 > > It's just a standard WAV file (not raw), so just open it in Audacity or > play it with sox. That's doing the trick. I was able to decode that with the SM1000 using its stock firmware, so now to see why my build didn't decode it. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
[Freetel-codec2] Fix for build error in SM1000 firmware since r2316
Hi all, I have a patch that fixes a build error in the SM1000 firmware due to an API change in revision 2316. Raw diff: http://git.longlandclan.yi.org/?p=for-upstream/freedv/codec2.git;a=commitdiff_plain;h=e63df653d1a9803e376723a6f9b17ee7bda580bf;hp=f5b636f202ccc0d125fd317507426f1fbeb493e1 Without, it triggers the following linker error: > src/sm1000_main.o: In function `main': > /home/stuartl/projects/sm1000/codec2/stm32/src/sm1000_main.c:348: undefined > reference to `freedv_zero_total_bit_errors' > collect2: error: ld returned 1 exit status > Makefile:677: recipe for target 'sm1000.elf' failed Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] 50mW!
On 23/09/15 09:29, David Rowe wrote: > Wow 50mW is amazing. Once nice feature about digital voice - once you > have enough power any further increases don't help. > > I have managed to get 0 BER over NVIS paths at my radios minimum power > (0.5W). It was annoying as I wanted errors but I couldn't get any! Indeed, the biggest limit to QRP is QRM at the receiver station. Where I am here in The Gap, I don't get a noise floor below S7 on 40m. QRP would struggle big time. On the bicycle, some areas are fine, others are real bad. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Tuning Aid 700B mode
On 15/09/15 18:42, David Rowe wrote: > The CPU load is proportional to the initial freq offset estimation > bandwidth. I'm inclined to wait a little and see if this is a real problem. Tuning accuracy is likely to be an issue on headless systems or for visually impaired operators. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Building FreeDV on Gentoo/AMD64: fails to pick up hamlib
Hi Richard, On 20/09/15 22:06, Richard Shaw wrote: > Any particular reason Gentoo installs like libraries to a private > directory? There's not likely to be a name clash of "libhamlib*" in > /usr/lib64. I'll see about adding /usr/lib64/hamlib to the search path. That I do not know. I thought it strange too when I first saw it, unless it's a "SLOT"-ed package, in which case it may be that depending on the version you install there might be a /usr/lib64/hamlibX where X represents some ABI number; thus allowing two parallel installations of hamlib without clashes. This is how wxWidgets is handled for example, so I have wx2.8 and 3.0 simultaneously on the machine, and there's a module for `eselect` that lets me choose which one is active. I had a bash at getting cmake to use what was reported from `pkg-config`, but in the end gave up and just did the final link step myself (after building with VERBOSE=1 to see what the link command was). That gave me a FreeDV binary. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Building FreeDV on Gentoo/AMD64: fails to pick up hamlib
On 20/09/15 18:35, Alexandru Csete wrote: > On Sun, Sep 20, 2015 at 1:36 AM, Stuart Longland > wrote: >> >> cmake doesn't like being told what to do either: >>> RC=0 stuartl@vk4msl-mb ~/hamradio/projects/fdmdv/freedv-build $ cmake -D >>> HAMLIB_LIBRARY=/usr/lib64/hamlib -D USE_STATIC_CODEC2=false ../freedv-1.0.1 >> >> … >> >> WARNING: Target "freedv" requests linking to directory "/usr/lib64/hamlib". >> Targets may link only to libraries. CMake is dropping the item. > > As I interpret this error, you have specified the hamlib directory but > you should have given the .so file, i.e. something like > > -DHAMLIB_LIBRARY=/usr/lib64/hamlib/libhamlib.so The trouble with that is there's also a libamlib++, and as it happens, it is used too. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Testing the SM1000 firmware
Hi Mark, On 20/09/15 10:53, Mark Jessop wrote: > You could also try this > file: https://www.dropbox.com/s/p52vjtgv1kw4k9e/vk100anzac_cq_1600.wav?dl=0 > > It's just a standard WAV file (not raw), so just open it in Audacity or > play it with sox. > > This was our "Voice Keyer" at the QSO party, so it has a CQ call, then > some silence. Ahh brilliant, wasn't aware of the freedv_tx program, and having that file should be a fairly good reference too. I think the best plan of attack regarding my firmware mods would be to backport them to the version released on the SM1000 (I'm not sure what revision number that was, but I'm told it was some time in March). Then I should be able to figure out what's broken. Regards, -- 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] Testing the SM1000 firmware
Hi all, What strategies do people use for testing the SM1000? I've had a report that the binary I built would not decode FreeDV 1600 signals. I just tried, and indeed, I could not get it, or the production binary, to decode a prepared signal sent from my laptop from the command line: My steps: $ sox ~/hamradio/projects/broadcast/vk4_warmup.mp3 -t raw -r 16000 -c 1 -b 16 -e signed-integer -L vk4-warmup.raw $ c2enc 1600 vk4-warmup.raw vk4-warmup.c2 $ fdmdv_mod vk4-warmup.c2 vk4-warmup.fdmdv $ sox -t raw -r 16000 -c 1 -b 16 -e signed-integer -L vk4-warmup.fdmdv -r 48000 -c 2 fdmdv.wav $ aplay -D hw:0,0 fdmdv.wav I used a cable to link the computer's output to the RIG SPKR jack on the SM1000. I ought to have heard the dulcet tones of Graham VK4BB announcing the times and frequencies of the WIA broadcast -- this is the recording that proceeds WIA News/QNews here in Queensland. Instead, I got mostly silence, save a few squawks from the SM1000. Is there some way that I can produce a reference FreeDV signal that the unit can decode? (The vk4_warmup.mp3 is from here: http://www.wiaq.com/ftp/vk4_warmup.mp3) -- 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
Re: [Freetel-codec2] Building FreeDV on Gentoo/AMD64: fails to pick up hamlib
On 20/09/15 09:16, Stuart Longland wrote: >> RC=0 stuartl@vk4msl-mb ~/hamradio/projects/fdmdv/freedv-build $ pkg-config >> --libs hamlib >> -L/usr/lib64/hamlib -lhamlib -lm > > It seems the cmake files could use a little help finding where hamlib > has been put. AFAIK there is a cmake module that can make use of > pkg-config, as I was using it some time back to locate Qt libraries in a > project at work. > cmake doesn't like being told what to do either: > RC=0 stuartl@vk4msl-mb ~/hamradio/projects/fdmdv/freedv-build $ cmake -D > HAMLIB_LIBRARY=/usr/lib64/hamlib -D USE_STATIC_CODEC2=false ../freedv-1.0.1 > -- FreeDV version: 1.0.1 > -- Build type not specified, defaulting to Release > -- Threads library flags: -lpthread > -- Looking for codec2... > -- codec2 library: /usr/local/lib64/libcodec2.so > -- codec2 headers: /usr/local/include/codec2 > -- Looking for portaudio... > -- portaudio library: portaudio;asound;m;pthread > -- portaudio headers: > -- Looking for hamlib... > -- Hamlib library: /usr/lib64/hamlib > -- Hamlib headers: /usr/include > -- Hamlib library found. > -- Looking for samplerate... > -- samplerate library: /usr/lib64/libsamplerate.so > -- samplerate headers: /usr/include > -- Looking for sox... > -- sox library: /usr/lib64/libsox.so > -- sox headers: /usr/include > -- Looking for sndfile... > -- sndfile library: /usr/lib64/libsndfile.so > -- sndfile headers: /usr/include > -- Looking for wxWidgets... > -- wxWidgets version: 3.0.0 > -- Will attempt static build of speex. > -- Build type will be: Release > -- Configuring done > WARNING: Target "freedv" requests linking to directory "/usr/lib64/hamlib". > Targets may link only to libraries. CMake is dropping the item. … > [100%] Building C object src/CMakeFiles/freedv.dir/sox_biquad.c.o > > Linking CXX executable freedv > > CMakeFiles/freedv.dir/hamlib.cpp.o: In function `Hamlib::Hamlib()': > > hamlib.cpp:(.text+0x888): undefined reference to `rig_set_debug' > hamlib.cpp:(.text+0x88d): undefined reference to `rig_load_all_backends' > hamlib.cpp:(.text+0x89d): undefined reference to `rig_list_foreach' > hamlib.cpp:(.text+0x983): undefined reference to `rig_set_debug' > CMakeFiles/freedv.dir/hamlib.cpp.o: In function `Hamlib::~Hamlib()': > hamlib.cpp:(.text+0xa15): undefined reference to `rig_close' > hamlib.cpp:(.text+0xa1d): undefined reference to `rig_cleanup' > CMakeFiles/freedv.dir/hamlib.cpp.o: In function `Hamlib::connect(unsigned > int, char const*)': > hamlib.cpp:(.text+0xb38): undefined reference to `rig_close' > hamlib.cpp:(.text+0xb40): undefined reference to `rig_cleanup' > hamlib.cpp:(.text+0xb56): undefined reference to `rig_init' > hamlib.cpp:(.text+0xb71): undefined reference to `rig_token_lookup' > hamlib.cpp:(.text+0xb7f): undefined reference to `rig_set_conf' > hamlib.cpp:(.text+0xb8f): undefined reference to `rig_open' > CMakeFiles/freedv.dir/hamlib.cpp.o: In function `Hamlib::ptt(bool)': > hamlib.cpp:(.text+0xbe8): undefined reference to `rig_set_ptt' > CMakeFiles/freedv.dir/hamlib.cpp.o: In function `Hamlib::close()': > hamlib.cpp:(.text+0xc53): undefined reference to `rig_close' > hamlib.cpp:(.text+0xc5b): undefined reference to `rig_cleanup' > collect2: error: ld returned 1 exit status > src/CMakeFiles/freedv.dir/build.make:418: recipe for target 'src/freedv' > failed > make[2]: *** [src/freedv] Error 1 > CMakeFiles/Makefile2:113: recipe for target 'src/CMakeFiles/freedv.dir/all' > failed > make[1]: *** [src/CMakeFiles/freedv.dir/all] Error 2 > Makefile:116: recipe for target 'all' failed > make: *** [all] Error 2 I'll see if I can cook up a patch that uses pkg-config. -- 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] Building FreeDV on Gentoo/AMD64: fails to pick up hamlib
130729) > * used by 8 other files > * - /usr/lib64/libswscale.so.2 > * - /usr/lib64/libswscale.so.2.2.100 > * used by /usr/bin/mencoder (media-video/mplayer-1.2_pre20130729) > * used by /usr/bin/mplayer (media-video/mplayer-1.2_pre20130729) > * used by /usr/lib64/kde4/ffmpegthumbs.so (kde-apps/ffmpegthumbs-4.12.5) > * used by /usr/lib64/libmediastreamer.so.1.0.0 > (media-libs/mediastreamer-2.8.2) > Use emerge @preserved-rebuild to rebuild packages using these libraries > bash: __gen_ps1: command not found > RC=0 vk4msl-mb freedv-build $ exit > RC=0 stuartl@vk4msl-mb ~/hamradio/projects/fdmdv/freedv-build $ cmake > ../freedv-1.0.1 > -- FreeDV version: 1.0.1 > -- Build type not specified, defaulting to Release > -- Threads library flags: -lpthread > -- Will attempt static build of codec2. > -- Looking for portaudio... > -- portaudio library: portaudio;asound;m;pthread > -- portaudio headers: > -- Looking for hamlib... > -- Hamlib library: HAMLIB_LIBRARY-NOTFOUND > -- Hamlib headers: /usr/include > CMake Error at CMakeLists.txt:295 (message): > hamlib not found. > > On Linux systems try installing: > > hamlib-devel (RPM based systems) > libhamlib-dev (DEB based systems) > > > -- Configuring incomplete, errors occurred! > See also > "/home/stuartl/hamradio/projects/fdmdv/freedv-build/CMakeFiles/CMakeOutput.log". > See also > "/home/stuartl/hamradio/projects/fdmdv/freedv-build/CMakeFiles/CMakeError.log". > RC=1 stuartl@vk4msl-mb ~/hamradio/projects/fdmdv/freedv-build $ ls -l > /usr/lib64/hamlib > total 1016 > drwxr-xr-x 2 root root 4096 Sep 20 09:08 hamlib > -rwxr-xr-x 1 root root 823912 Sep 20 09:08 hamlibtcl-1.0.so > -rwxr-xr-x 1 root root 1007 Sep 20 09:08 hamlibtcl.la > lrwxrwxrwx 1 root root 16 Sep 20 09:08 hamlibtcl.so -> hamlibtcl-1.0.so > lrwxrwxrwx 1 root root 19 Sep 20 09:08 libhamlib.so -> libhamlib.so.2.0.16 > lrwxrwxrwx 1 root root 21 Sep 20 09:08 libhamlib++.so -> > libhamlib++.so.2.0.16 > lrwxrwxrwx 1 root root 19 Sep 20 09:08 libhamlib.so.2 -> > libhamlib.so.2.0.16 > lrwxrwxrwx 1 root root 21 Sep 20 09:08 libhamlib++.so.2 -> > libhamlib++.so.2.0.16 > -rwxr-xr-x 1 root root 142688 Sep 20 09:08 libhamlib.so.2.0.16 > -rwxr-xr-x 1 root root 51104 Sep 20 09:08 libhamlib++.so.2.0.16 > drwxr-xr-x 2 root root 4096 Sep 20 09:08 pkgconfig > -rw-r--r-- 1 root root 81 Sep 20 09:08 pkgIndex.tcl > RC=0 stuartl@vk4msl-mb ~/hamradio/projects/fdmdv/freedv-build $ pkg-config > --libs hamlib > -L/usr/lib64/hamlib -lhamlib -lm It seems the cmake files could use a little help finding where hamlib has been put. AFAIK there is a cmake module that can make use of pkg-config, as I was using it some time back to locate Qt libraries in a project at work. -- 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
Re: [Freetel-codec2] Silly question regarding SM-1000 sample rate
On 20/09/15 03:43, Tomas Härdin wrote: > Couldn't you do further low-pass filtering in software, then decimate to > 8 kHz? (caveat: I haven't checked if the code actually does this) That's exactly what it does. It samples at 16kHz from the ADC, filters it to produce an 8kHz stream. Actually a thought just occurred, could we just do nearest-neighbour upsampling to get back to 16kHz? I'll admit I havent looked at what algorithm is used to do the resampling, however this is not a device that will be used by audiophiles (it doesn't do 192kHz 32-bit FLAC for starters) so linear interpolation or nearest-neighbour would probably work for getting it back to 16kHz. -- 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] SM1000 menu patchset
Just a heads up, I've thrown the contents of the patchset up on a site so you can pick through them at your leisure. There is also a compiled .bin file. https://stuartl.longlandclan.id.au/freedv/sm1000/2015-09-04/ This is against revision 2295 of Subversion, I tried a rebase against the current head, but that failed to build so for now I'll release this since I know things work there. This is a work in progress. At the moment, I have Morse announcements of the different modes, and so as you hit select you first hear a 'beep' acknowledgement, then a moment later the announcement of the mode. If you hit a button before the announcement, the announcement is cancelled. (In the case of the SELECT button, a new announcement will happen instead after a delay.) -- 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
Re: [Freetel-codec2] Tone generator, sound effects for the SM1000.
On 19/09/15 10:59, Brady O'Brien wrote: > The fifo and dac patches have been applied to codec2-dev and committed > to the SVN repo. > > Thanks for contributing, Stuart! No problems, great to help. I've got a couple more that just adds an announcement of the current mode when the SELECT button is hit, that allows the user to know what mode they're in. I've noticed the SysTick interrupt seems to be somewhat off from the 1kHz (seems more 2MHz), which made timing fun, but things seem to be performing. I also notice the TONE mode seems broken (I get the colourful loop of death), since I've got a new tone generator, I'll use that to fix it. Regards, -- 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
Re: [Freetel-codec2] Tone generator, sound effects for the SM1000.
On 19/09/15 10:29, Brady O'Brien wrote:
>
> Are you developing under codec2-dev from the SVN repository? I could add
> a dacN_fifo_free to stm32f4_dac.c and push it up for you, if you're not
> already moving on it.
I'm not directly working from SVN, but rather a `git svn clone`
check-out of it so that I can commit my changes. In any case, you were
right, it was trivial to add.
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
>From 97698ae33bbbc59aa050ccbc93c263da982cebec Mon Sep 17 00:00:00 2001
From: Stuart Longland
Date: Sat, 19 Sep 2015 10:28:55 +1000
Subject: [PATCH 5/6] fifo: Add fifo_free function, const correctness.
Add a new function for the FIFO routines that returns the free space in
a FIFO.
The code was actually nicked out of fifo_write, just made into its own
function so that other code can make use of it.
---
src/codec2_fifo.h | 11 ++-
src/fifo.c| 17 +
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/src/codec2_fifo.h b/src/codec2_fifo.h
index dc93e15..383254f 100644
--- a/src/codec2_fifo.h
+++ b/src/codec2_fifo.h
@@ -42,7 +42,16 @@ struct FIFO *fifo_create(int nshort);
void fifo_destroy(struct FIFO *fifo);
int fifo_write(struct FIFO *fifo, short data[], int n);
int fifo_read(struct FIFO *fifo, short data[], int n);
-int fifo_used(struct FIFO *fifo);
+
+/*!
+ * Return the number of bytes stored in the FIFO.
+ */
+int fifo_used(const struct FIFO * const fifo);
+
+/*!
+ * Return the space available in the FIFO.
+ */
+int fifo_free(const struct FIFO * const fifo);
#ifdef __cplusplus
}
diff --git a/src/fifo.c b/src/fifo.c
index 566d77a..d562a6a 100644
--- a/src/fifo.c
+++ b/src/fifo.c
@@ -64,19 +64,13 @@ void fifo_destroy(struct FIFO *fifo) {
int fifo_write(struct FIFO *fifo, short data[], int n) {
inti;
-intfifo_free;
short *pdata;
short *pin = fifo->pin;
assert(fifo != NULL);
assert(data != NULL);
-// available storage is one less than nshort as prd == pwr
-// is reserved for empty rather than full
-
-fifo_free = fifo->nshort - fifo_used(fifo) - 1;
-
-if (n > fifo_free) {
+if (n > fifo_free(fifo)) {
return -1;
}
else {
@@ -125,7 +119,7 @@ int fifo_read(struct FIFO *fifo, short data[], int n)
return 0;
}
-int fifo_used(struct FIFO *fifo)
+int fifo_used(const struct FIFO * const fifo)
{
short *pin = fifo->pin;
short *pout = fifo->pout;
@@ -140,3 +134,10 @@ int fifo_used(struct FIFO *fifo)
return used;
}
+int fifo_free(const struct FIFO * const fifo)
+{
+// available storage is one less than nshort as prd == pwr
+// is reserved for empty rather than full
+
+return fifo->nshort - fifo_used(fifo) - 1;
+}
--
2.4.6
>From d19c5929e3c1a89e74b8c9a85eb4ad789384922c Mon Sep 17 00:00:00 2001
From: Stuart Longland
Date: Sat, 19 Sep 2015 10:30:24 +1000
Subject: [PATCH 6/6] stm32f4_dac: Add dac[12]_free.
Returns the number of samples available in the buffer.
---
stm32/inc/stm32f4_dac.h | 2 ++
stm32/src/stm32f4_dac.c | 8
2 files changed, 10 insertions(+)
diff --git a/stm32/inc/stm32f4_dac.h b/stm32/inc/stm32f4_dac.h
index d0b8259..aa30415 100644
--- a/stm32/inc/stm32f4_dac.h
+++ b/stm32/inc/stm32f4_dac.h
@@ -32,6 +32,8 @@
void dac_open(int fifo_sz);
int dac1_write(short buf[], int n); /* DAC1 pin PA4 */
+int dac1_free();
int dac2_write(short buf[], int n); /* DAC2 pin PA5 */
+int dac2_free();
#endif
diff --git a/stm32/src/stm32f4_dac.c b/stm32/src/stm32f4_dac.c
index d160454..f78004d 100644
--- a/stm32/src/stm32f4_dac.c
+++ b/stm32/src/stm32f4_dac.c
@@ -111,6 +111,14 @@ int dac2_write(short buf[], int n) {
return fifo_write(dac2_fifo, buf, n);
}
+int dac1_free() {
+return fifo_free(dac1_fifo);
+}
+
+int dac2_free() {
+return fifo_free(dac2_fifo);
+}
+
static void tim6_config(void)
{
TIM_TimeBaseInitTypeDefTIM_TimeBaseStructure;
--
2.4.6
--
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Tone generator, sound effects for the SM1000.
On 19/09/15 10:08, Brady O'Brien wrote: > Also, If you've got an STM32F4 Discovery (and probably other > stm32*discovery boards with stlink), you should be able to use the > onboard stlink debugger with the SM1000. SWD is broken out on header CN1 > of the SM1000D. Yeah, I don't at this point, otherwise I'd be using that to develop since it probably has headers for JTAG too. I have a little Olimex JTAG dongle I use for debugging on Cortex M3 boards, which makes life a lot easier. > On Fri, Sep 18, 2015 at 7:04 PM, Brady O'Brien > mailto:brady.obrien...@gmail.com>> wrote: > > > I'm pretty sure dac_write is nonblocking. If memory serves me > correctly, it returns -1 if there's not enough free space in the > fifo, 0 otherwise. Ahh bingo! Right, I'll check for that and see what happens. Is there a way to see how much space there is in the FIFO? Otherwise I've got to try and guess, then "re-wind" N samples to try and play them again later, or stash them somewhere to be retried. -- 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
Re: [Freetel-codec2] Tone generator, sound effects for the SM1000.
On 19/09/15 07:56, David Rowe wrote:
> Thank you Stuart - I think that's the first patch for the SM1000! Well
> done.
>
> I'm camping this weekend at Mt Remarkable but will take a look at the
> patches early next week and figure out where they fit in.
No problems there. I've been tinkering around with that for a bit now.
One thing I do notice is that timing seems to be off, I'm not sure why.
Perhaps I'm overrunning a buffer somewhere? Still getting to grips with
how the DAC code works. I hacked up a version of the DAC unit test with
this:
int main(void) {
struct tone_gen_t tone_gen;
dac_open(4*DAC_BUF_SZ);
while(1) {
tone_reset(&tone_gen, 500, 400);
while (tone_gen.remain) {
int16_t buffer[800];
int count;
for (count = 0; (count < 800) && tone_gen.remain; count++)
buffer[count] = tone_next(&tone_gen);
dac1_write(buffer, count);
dac2_write(buffer, count);
}
tone_reset(&tone_gen, 1000, 100);
while (tone_gen.remain) {
int16_t buffer[800];
int count;
for (count = 0; (count < 800) && tone_gen.remain; count++)
buffer[count] = tone_next(&tone_gen);
dac1_write(buffer, count);
dac2_write(buffer, count);
}
}
}
That should be, a 1kHz tone every 500 msec with a 500Hz tone the rest of
the time.
######## …
Instead I get a burst of stuttery 1kHz beeps in amongst a drone of 500Hz.
-#-#-#-#---#-#-#-#---#-#-#-#- …
Not sure what's going on there. It might need to wait until I pick up a
suitable STM32F4-based board that I can hook my JTAG to.
If I write a quick C program on my host that `fwrite`s the samples to
stdout, and pipe that to `aplay`, it works fine.
I also have a morse code generator (attached) that can take an arbitrary
string and play it as morse at any speed and frequency. Speed is set by
the "dit" time. I figure the user can set a preferred speed in WPM that
we translate to "dit milliseconds" using some standard like the PARIS
standard. The word "PARIS" is 50 dits long → Wikipedia reckons that
equates to T=1200/W where T is in milliseconds and W is words per minute.
An example program:
#include
#include "morse.h"
int main(void) {
struct morse_player_t mp;
mp.freq = 800;
mp.dit_time = 100;
morse_play(&mp, "TESTING 1 2 3 4");
while(mp.msg) {
int16_t sample = morse_next(&mp);
fwrite(&sample, sizeof(sample), 1, stdout);
}
return(0);
}
This command plays nice clean morse on my host with the above code:
gcc -I src -o test test.c src/tone.c src/sfx.c src/morse.c \
&& ./test | aplay -c 1 -f S16_LE -r 16000 -
So the building blocks for a menu system are there. More work is needed
on the playback side of things (as discussed) and of course, detecting
long vs short presses of buttons, but things are moving somewhat.
A module that handles playback of pre-recorded Codec2 samples would be a
next step after getting some basic menu logic together, that would allow
for voice prompts (rather than morse).
I'll look at that after I get something basic going.
> If you, or anyone else reading, is interested, it would be great to have
> some help porting the cohpsk modem to the SM1000. A first step would be
> to look at the memory usage, like I did for the fdmdv modem:
>
>http://www.rowetel.com/blog/?p=3427
Can't promise anything there, but I can have a look.
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
From e76cd190ce0bbb597a19bfa9cfe4b8965cae9e2b Mon Sep 17 00:00:00 2001
From: Stuart Longland
Date: Sat, 19 Sep 2015 09:48:12 +1000
Subject: [PATCH 4/4] morse: Morse code player module.
This is a code module that can play arbitrary morse-code symbols using
the 'sfx' module to control tones. The module can be set to any
frequency and speed (the time of a "dit" in milliseconds).
At present, I support the letters and digits, no punctuation, but those
can be added, suitable tables will need to be defined for those.
---
stm32/src/morse.c | 175 ++
stm32/src/morse.h | 65
2 files changed, 240 insertions(+)
create mode 100644 stm32/src/morse.c
create mode 100644 stm32/src/morse.h
diff --git a/stm32/src/morse.c b/stm32/src/morse.c
new file mode 100644
index 000..2522993
--- /dev/null
+++ b/stm32/src/morse.c
@@ -0,0 +1,175 @@
+/*!
+ * Morse code library.
+ *
+ * This implements a state machine for playing back morse code messages.
+ *
+ * Author Stuart Longland
+ * Copyright
Re: [Freetel-codec2] Silly question regarding SM-1000 sample rate
Hi David & Glen, On 18/09/15 16:13, glen english wrote: > If we were to sample at 8kHz, our nyquist frequency is 4kHz of course. > Any spectral information above the nyquist rate will be aliased bay into > the baseband, IE below the nyquist rate. > > IF we assume we don't care about aliases between 3.4 and 4kHz, then this > allows for signals up to 4.0 - 3.4 = 0.6, and 0.6+Fyquist(4kHz) = > 4.6kHz. (as a 4.5kHz signal will get aliased to 3.5 kHz.) Fair enough. I just wondered, seemed that we could save some CPU processing power if we used a lower rate, but good point on the analogue filtering, I wasn't thinking of that side of things. Definitely we want to avoid nasty aliasing, and having a higher rate does make the filter cutoff less critical. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
[Freetel-codec2] Tone generator, sound effects for the SM1000.
Well, the first fruits of my labour. I have some patches that implement
a tone generator and sound effect sequencer.
This could be useful for implementing the TONE feature, we can also
implement a crude "sweep" function for bandpass testing of rigs.
Frequency accuracy is not super-accurate, but I did try some numbers,
and at worst it seemed to be about 6% off.
The tone generation is fixed-point and the output is unscaled.
With my current builds, I note hitting PTT when in TONE mode immediately
dumps me in the colourful ring of death routine. We should be able to
use this to perform the same function.
example-usage.diff is an example using the current Subversion head code.
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
From 37e4cbfa72e54ac61018edd5819f79d126b51d95 Mon Sep 17 00:00:00 2001
From: Stuart Longland
Date: Fri, 18 Sep 2015 18:29:50 +1000
Subject: [PATCH 1/3] tone: Fixed-point tone generator.
This is a simple fixed-point tone generator. Most frequencies can be
generated with at most about 6% error, which should be "good enough" for
audio alerts.
---
stm32/src/tone.c | 114 +++
stm32/src/tone.h | 84
2 files changed, 198 insertions(+)
create mode 100644 stm32/src/tone.c
create mode 100644 stm32/src/tone.h
diff --git a/stm32/src/tone.c b/stm32/src/tone.c
new file mode 100644
index 000..7f02fa5
--- /dev/null
+++ b/stm32/src/tone.c
@@ -0,0 +1,114 @@
+/*!
+ * Fixed-point tone generator.
+ *
+ * The code here implements a simple fixed-point tone generator that uses
+ * integer arithmetic to generate a sinusoid at a fixed sample rate of
+ * 16kHz.
+ *
+ * To set the initial state of the state machine, you specify a frequency
+ * and duration using tone_reset. The corresponding C file embeds a
+ * sinusoid look-up table. The total number of samples is computed for
+ * the given time and used to initialise 'remain', 'time' is initialised
+ * to 0, and 'step' gives the amount to increment 'time' by each iteration.
+ *
+ * The samples are retrieved by repeatedly calling tone_next. This
+ * advances 'time' and decrements 'remain'. The tone is complete when
+ * 'remain' is zero.
+ *
+ * Author Stuart Longland
+ * Copyright (C) 2015 FreeDV tors.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU Lesser General Public License version 2.1,
+ * as published by the Free Software Foundation. This program is
+ * distributed in the hope that it will be useful, but WITHOUT ANY
+ * WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this program; if not, see
+ * <http://www.gnu.org/licenses/>.
+ */
+
+#include "tone.h"
+
+/*! Fixed-point shift factor */
+#define TONE_SHIFT (12)
+
+/*! Static compiled sinusoid. Nicked from original FreeDV code. */
+static const int16_t tone_sine[] = {
+ -16,6384, 12528, 18192, 23200, 27232, 30256, 32128,
+ 32752, 32128, 30256, 27232, 23152, 18192, 12528,6384,
+ -16, -6416, -12560, -18224, -23184, -27264, -30288, -32160,
+ -32768, -32160, -30288, -27264, -23184, -18224, -12560, -6416
+};
+
+/*! Length of sinusoid in samples */
+#define TONE_SINE_LEN (sizeof(tone_sine)/sizeof(tone_sine[0]))
+
+/*!
+ * Re-set the tone generator.
+ *
+ * @param tone_gen Tone generator to reset.
+ * @param freq Frequency in Hz, 0 = silence.
+ * @param duration Duration in milliseconds. 0 to stop.
+ */
+void tone_reset(
+ struct tone_gen_t* const tone_gen,
+ uint16_t freq, uint16_t duration)
+{
+ if (freq)
+ /* Compute the time step */
+ tone_gen->step = (((2*freq*TONE_SINE_LEN) << TONE_SHIFT)
+/ ((2*TONE_FS) + 1) + 1);
+ else
+ /* DC tone == silence */
+ tone_gen->step = 0;
+
+ /* Compute remaining samples */
+ tone_gen->remain = (uint16_t)(
+ ((uint32_t)(TONE_FS * duration)) / 1000);
+
+ /* Initialise the sample counter */
+ tone_gen->sample = 0;
+}
+
+/*!
+ * Retrieve the next sample from the tone generator.
+ * @param tone_gen Tone generator to update.
+ */
+int16_t tone_next(
+ struct tone_gen_t* const tone_gen)
+{
+ if (!tone_gen)
+ return 0;
+ if (!tone_gen->remain)
+ return 0;
+ if (!tone_gen->step) {
+ /* Special case, emit silence */
+ tone_gen->remain--;
+ return 0;
+ }
+
+ /* Compute sample index */
+ uint16_t sample_int = ((tone_gen->sample) >> TONE_SHIFT)
+% TONE_SINE_LEN;
+
+ /* Advance tone generator state */
+ tone_gen->sample += tone_gen->step;
+ tone_gen->remain--;
+
+ return tone_sine[sample_int];
+}
+
+/*!
+
[Freetel-codec2] Silly question regarding SM-1000 sample rate
Hi all, Just looking at the source code, it hit me. When in analogue mode, we run 16kHz sample rate, fair enough. But in DV mode, we sample the ADC at 16kHz, downconvert to 8kHz, pass it through the modem and codec, then upconvert back to 16kHz for the DAC. We're dealing with voice frequencies, with SSB transmit bandwidths of less than 3kHz. Why not do the whole lot at 8kHz and save some CPU time? Maybe some rate-switching when in analogue or DV mode might be an option too, so we run ADC/DAC at full-rate in analogue (for higher fidelity), then switch to half-rate when we're doing DV. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Now I have a disco light…
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi David, On 14/09/15 06:09, David Rowe wrote: > Rather than a debugger I'd just using a codec-dev release from > March, see if that works, then work fwd to see what changed. Much > easier to start with something that works. Well, a big factor is the toolchain I was using. I was using one compiled using the `crossdev` tool in Gentoo Linux, which basically takes the standard 'ebuild' files that Gentoo uses for the host toolchain and does some environment setting voodoo to influence these into producing a cross compiler. It worked well for Cortex M3 development, but not so good for the Cortex M4, particularly hard-float. The toolchain mentioned in the README works, although I'd like to be able to reproduce the toolchain used so that I can ensure future compatibility. I guess I'm just used to DIY toolchains because years ago I didn't have much choice. > I'll be looking at SM1000 firmware again later this year when a > 700 mode is ported. Would really appreciate some help with this > if anyone is interested! > > Stuart - you approach and code for inserting audio looks fine to > me, and the fact that it works in analog mode is a good start. Indeed, that is promising. I'm not sure that porting the 700(B) mode is within my skill set yet. The plan so far is that I improve the UI to allow selection between the different modes and for configuration of other options. That would let me scratch some itches I have now, and facilitate future improvements. > To measure CPU load I use blinky GPIO pins and an oscilloscope. Yeah, I figured as much. I see in part of that look: > GPIOE->ODR &= ~(1 << 3); and a similar line that sets bit 3 of GPIOE->ODR; I'm guessing that is the blinky GPIO pin you're referring to? Regards, - -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV9eRKAAoJEE36GRQQveO3zNYP/2Nm2je8VQiZ74/PcQmY4hki 4/G3ji/lLnL8etKSE7UxG0zWZdw3xeu4D/Cdjyar+3Tm27gAicI4W6MQ7VDOhben O3UJZ1zwcfyRE65prR5khoSg/s2FWSN77lk70g7DwLTciyW9RAYc3WUS8aztAt5p +WM4ze92yOk4XF6NOGCoBw2YEWiOapuSDjXajCo0rjnNKcWOp3pxsqr+ftdZwncm oL2dbDwYW5fKlpJKM45DZlOBHv9kCuP+lG/AYwRx70D/aM77UNTSErXcWg4CzXCG +ZZZiKcXQHVfw77uwHIzYnZxWcEIr6gx4JNe0wth8EydZ810M/cExGqlH8q497Yv p10E/FCfYRcZfR+a/ynMEssEOX/Ci7MpwvMd1heGJX8a+8GZJFcXznTN2lEG1wDq 463Ds4Yjh1Ssb5xFSfiykGlMLuJbzAokm9zjGGKRxpEPhge4fRe/eft30sRsihdQ 0eZRkr6Xxt0pMpZKLcTSEv+Rxr6bjNoTKbg/sXrJJDdtf9xIepp6vTXIfYqQSHV0 QJ9DmJfAFZ6IvwH2rSKoSkkIuqBT1XPqmwyWhTlM6bqIOzlH/Ah4jfcxj8TEjai7 QPe+LntLY10zLB/Z1iUHRbx8YaZGysVF6UkiR6RVSQXPX92bQdIyG0lRuztWr57U 5vz8ilnnQ1IvwmfBnKXO =zJNU -END PGP SIGNATURE- -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Now I have a disco light…
On 13/09/15 18:39, Stuart Longland wrote: > The frequency sounds like a 500 Hz tone. When in analogue mode, it's > clear, but in DV/TONE mode it is "broken", sounds like a string of > high-speed morse "dits" and lasts twice as long. I can't quite figure > out where the gaps are coming from. I fiddled a bit more, it only happens when the FDMDV modem is active, which makes me think about spare CPU time. Maybe I'm just pushing the little ARM a bit too much. The way forward might be if there's a menu prompt to play, we play that and ignore the ADCs for a while. I'm not sure what that means for the FIFO queues that look after ADC inputs, whether they just push old samples off the end or what happens. Anyway, it's past my bed time now. I'll be thinking about it on my way to work tomorrow at 4:30AM. ;-) Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
Re: [Freetel-codec2] Now I have a disco light…
On 13/09/15 17:04, David Rowe wrote:
> You may have hit the "colorful ring of death", which is where asserts()
> end up on STM32F4 systems. I haven't tested a recent build of the
> SM1000 firmware myself.
Ahh that explains it. So I'll need a debugger to see what's going on.
I've got something going using the gcc-arm-embedded toolchain, but it
seems my own toolchain will have to wait.
> For comparison I have posted the sm1000.bin image we built in March,
> that is used for the current production SM1000s. See item 1 of "Testing,
> Debugging, Development Notes" on the SM1000 page for the link.
I've stashed that file for future reference, since it seems it's
toolchain related. Thanks for that.
I've got things going for now, at the moment I'm working on generating
tones through the speaker by mixing in a sine.
I figure that regardless of whether the audio comes from recordings or
as morse, I'm going to have to figure out how to get them into the audio
buffer.
For now I've just created a simple structure:
> struct buzzer_state {
> /*! Number of samples remaining. */
> unsigned short remain;
> /*! Current buzzer sinewave sample. */
> unsigned char sample;
> };
and two functions:
> /*! Start the buzzer for the next len samples */
> void buzzer_start(struct buzzer_state* bs, unsigned short len) {
> bs->remain = len;
> }
>
> /*! Get the next sample for the buzzer */
> short buzzer_next_sample(struct buzzer_state* bs) {
> if (!bs)
> return 0;
> if (!bs->remain)
> return 0;
> short sample = aSine[bs->sample] >> 1;
> bs->sample = (bs->sample + 1) % SINE_SAMPLES;
> bs->remain--;
> return sample;
> }
So in theory, I can call buzzer_start, and give it a number of samples
to count down. Each time buzzer_next_sample is called, it emits the
next sample in the sine then decrements the counter. I simply need to
add the output of this to the audio feed.
There are two places that I see audio being written, basically in the
receive path. So I tried the following:
> if (ss.mode == ANALOG) {
>
> if (adc1_read(&adc16k[FDMDV_OS_TAPS_16K], n_samples_16k) ==
> 0) {
> fdmdv_16_to_8_short(adc8k, &adc16k[FDMDV_OS_TAPS_16K],
> n_samples);
> for(i=0; i dac8k[FDMDV_OS_TAPS_8K+i] = adc8k[i];
> fdmdv_8_to_16_short(dac16k, &dac8k[FDMDV_OS_TAPS_8K],
> n_samples);
>
> if (bs.remain) {
> for(i=0; i < n_samples_16k; i++)
> dac16k[i] += buzzer_next_sample(&bs);
> }
>
> dac2_write(dac16k, n_samples_16k);
> led_rt(0); led_err(0);
>}
> }
> else {
>
> /* regular DV mode */
>
> nin = freedv_nin(f);
> nout = nin;
> freedv_zero_total_bit_errors(f);
>
> if (adc1_read(&adc16k[FDMDV_OS_TAPS_16K], 2*nin) == 0) {
> GPIOE->ODR = (1 << 3);
> fdmdv_16_to_8_short(adc8k, &adc16k[FDMDV_OS_TAPS_16K],
> nin);
> nout = freedv_rx(f, &dac8k[FDMDV_OS_TAPS_8K], adc8k);
> fdmdv_8_to_16_short(dac16k, &dac8k[FDMDV_OS_TAPS_8K],
> nout);
>
> nout *= 2;
> if (bs.remain) {
> for(i=0; i < nout; i++)
> dac16k[i] += buzzer_next_sample(&bs);
> }
>
> dac2_write(dac16k, nout);
> led_rt(freedv_get_sync(f));
> led_err(freedv_get_total_bit_errors(f));
> GPIOE->ODR &= ~(1 << 3);
> }
> }
The frequency sounds like a 500 Hz tone. When in analogue mode, it's
clear, but in DV/TONE mode it is "broken", sounds like a string of
high-speed morse "dits" and lasts twice as long. I can't quite figure
out where the gaps are coming from.
As I understand it, nout is the number of samples to be placed in the
DAC output buffer, and dac16k is the array the samples come from.
They're 16-bit integers that get scaled down to 12-bit. I'm iterating
over that array and mixing my samples in, but it seems I'm not getting
all of them: half get to the DAC un-mixed.
I figure that the receive audio should be audible whilst in menu mode,
that's what I'm shooting for right now, and I don't think it's infeasible.
Is there some other area I've missed where DAC2 gets written to?
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
signature.asc
Description: OpenPGP digital signature
--
___
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
[Freetel-codec2] Now I have a disco light…
Hi all, A week or two back, I tried building FreeDV for the SM-1000, but never got around to flashing it to the unit. I finally did that this afternoon. I now have it flashing in sequence: Power, PTT, Sync, Clip/Error. Did I flash the wrong .bin file? -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature -- ___ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
