Single chip AM radio on a microcontroller - Page 1
Forum section: electronics / projects

author: Howardlong
author_rank: Super Contributor
timestamp: August 17, 2025, 06:34:42 pm
content: One from the "because you can" bucket for you.Here is an AM Radio covering long and medium wave running on a dsPIC33AKMC102 28 pin microcontroller: antenna in, audio out. There are no other active devices between the antenna and the audio output. (OK, there is an I2C LCD display).Almost all the processing is done using single precision floating point, including the quadrature local oscillator, mixer, low pass filtering, decimation, demodulation, and AGC. The dsPIC33A series has a trick up its sleeve for software defined radio: sin() and cos() are performed in silicon, each in 4 cycles, and you can reduce that to 1 cycle effective if you're smart with re-ordering your instructions in the pipeline.31.4k bytes of compiled code, half of that is for the macro-expanded unrolled assembler.73.6% of the CPU is taken up performing the signal processing.Current draw at 3.3V: 69mA NICE!I last did this on ARM M4F with an LPC4370 some years ago. That was rather compromised because it was undersampling, at 2MSa/s, and it used about 95% of the CPU even then, with some hand-rolled assembler in the pinch points. I have used the same approach here, except for the filtering aspect, and I've added the non-essentials ;-) like a tuning knob and a display.Code is attached, needs MPLAB X 6.25 and XC-DSC 3.21. It uses -O3 optimisation for some functions, but will also work with the free -O2 albeit with a little more CPU usage (76.1% up from 73.6%).Here's an extract from a more detailed description in the projects the main.c heading, describing how the firmware works at a high level:Code:// AM radio receiver with LCD display and rotary encoder tuning.//// Channel spacing is set for ITU regions 1 & 3, i.e. 9kHz.// LW & MW bands are set to the UK allocation.// You can change this within in the two CLC interrupts.//// DSP Processing Overview// Almost the entire DSP processing is performed in single precision// floating point. Only the ADC input samples and DAC output samples are// in integer.// The logical flow is:// ADC Samples// Mix with Quadrature LO (direct conversion)// Low pass filter// Decimate// Demodulate & AGC//// DSP Processing flow detail...// Ping/pong ADC DMA buffer, produces 128 samples at a time for processing.// Each unsigned integer sample is 13 bits at 4MSa/s from ADC.// Each sample is corrected to signed.// Each signed sample is converted to float.// Each float sample is multiplied with sin(Phi) and cos(Phi) to give I// and Q mixed with the frequency in question.// Phi is incremented commensurate with desired operating frequency, ready// for next sample.// I & Q Samples filtered and decimated by 128 with a seven stage polyphase// deconstructed non-recursive 3rd-order CIC filter to give 31.25kSa/s// (see Richard Lyons "Understanding Digital Signal Processing" 2nd// edition section 13.24).// I & Q filtered outputs scaled (due to filter gain).// Phi is checked for value over 2 * PI, and adjusted as necessary to// avoid future excessive frequency inaccuracies.// 31.25kSa/s I & Q stream further filtered with a 16 tap 6kHz low pass FIR// compensation filter. See Matlab code referenced here:// https://www.dsprelated.com/blogimages/RickLyons/CIC_digital_filters-Ver_3-Lyons.pdf// (also runs in Octave).// FIR result samples demodulated with simple SQRT(I^2 + Q^2).// AGC applied giving audio output.// Convert to 12 bit unsigned integer for DAC// Result fed to DAC DMA managed ping/pong buffer.

author: MikeK
author_rank: Super Contributor
timestamp: August 17, 2025, 09:34:06 pm
content: Nice! It might be useful to the high-altitude balloon people for a cheap backup beacon.Is filtering necessary on the output?...Just realized that it's only a receiver.This reminds me that I let my ham license lapse earlier this year and should renew it for some tinkering again.

author: themadhippy
author_rank: Super Contributor
timestamp: August 17, 2025, 09:45:47 pm
content: How times change ,they used to use a radio to get audio from early micros and now were getting radio out of micros

author: MK14
author_rank: Super Contributor
timestamp: August 17, 2025, 10:12:04 pm
content: In the video, it seems to ask about what a mysterious 144kHz morse code like signal is.In another video I watched recently, it explained about them, being related to Russian (secret) Military transmissions.Off-hand, I'm not sure which video it was, so I can't link to it.But google, is my friend, here:https://en.wikipedia.org/wiki/UVB-76Which seems to be almost exactly 32 times the frequency you seem to mention.Could that be, a FEATURE of your software, that it picks up, certain multiples (or lower frequencies) of the original signal or something?Edit:Added the following..From the wiki (I put the 32 number in):4625 kHz / 32 = 144.53125 kHz = About the frequency you seemed to displayThis seems to be the video, I watched, recently (before this thread existed):

author: brucehoult
author_rank: Super Contributor
timestamp: August 18, 2025, 12:25:00 am
content: Quote from: Howardlong on August 17, 2025, 06:34:42 pmIt seems weird to need high performance sin and cos here. Do you really?Things I'm familiar with are usually fine with stepping a sin and cos (x and y, r and i) around a circle using the rotation matrix (two fmul, two fmadd/sub) of a step angle.Is there something unique meaning this couldn't be ported easily to a C-M4F?

author: Howardlong
author_rank: Super Contributor
timestamp: August 18, 2025, 04:14:07 am
content: Quote from: brucehoult on August 18, 2025, 12:25:00 amThis was how I did it with M4F several years ago on an LPC4370. M4F and M7 don’t have hardware sin and cos.(It didn't have a hardware oversampling ADC, opamps or DAC either… the USP with this project is that the entire chain from antenna to audio out is done in a single chip).I covered that project here:https://youtu.be/lD3WSCN-5u0This was a bit of a cheat because it only sampled at 2MSa/s so used subsampling above 1MHz, and it still took well lver 90% of the CPU. It did, however, use a different filtering method with a polyphase FIR filter prior to decimation rather than a polyphase deconstructed non-recursive CIC plus decimator followed by an FIR compensation filter.There’s a problem with the rotation method in that it can accumulate errors over time in terms of maintaining both gain and phase. You can correct for this, but it is extra processing.In fixed point, it’s even harder to keep on that unit circle.FWIW, the original version of this implementation was done in fixed point.When you have a sin and cos that take a single cycle each of you’re clever with your pipelining, why reinvent the wheel (pun intended)?

author: brucehoult
author_rank: Super Contributor
timestamp: August 18, 2025, 05:02:09 am
content: Quote from: Howardlong on August 18, 2025, 04:14:07 amYes, but so can the angle you're inputting into the sine and cosine instructions, especially if it's expressed in radians.If the angle divides evenly into 360º (or some multiple of it) then you can clamp either the angle to 0 or the sin to 0 and cos to 1 each N times around equally easily.

author: Analog Kid
author_rank: Super Contributor
timestamp: August 18, 2025, 05:15:11 am
content: And I thought making an AM radio using just a 555 was pretty kewl ...

author: Howardlong
author_rank: Super Contributor
timestamp: August 18, 2025, 06:38:00 am
content: Quote from: MK14 on August 17, 2025, 10:12:04 pmI am sure it is a "feature", as it doesn't come up on a commercial radio using the same antenna.There is an RTTY signal on 146kHz, within the receiver's AM passband at 144kHz, but that is FSK, not AFSK, and it doesn't sound like this weird signal.On that basis I'm happy to regard it as a mystery.

author: Howardlong
author_rank: Super Contributor
timestamp: August 18, 2025, 06:53:07 am
content: Quote from: brucehoult on August 18, 2025, 05:02:09 amThat's why I do this, mentioned in the OP.Code:// Phi is checked for value over 2 * PI, and adjusted as necessary to// avoid future excessive frequency inaccuracies....and here's the code from the project I attached...Code:// Keep _fLOPhase within 2 * PI to avoid mantissa truncation and excessive inaccuracies when adding relatively small incremental valuesif (_fLOPhase >= PI_MUL_2){float fIntSub=((int)(_fLOPhase * ( 1.0/PI_MUL_2 ) ) ) * PI_MUL_2;_fLOPhase -= fIntSub;}But I only do this once every 128 samples, so it's trivial in terms of both coding and CPU effort.I'll add that it's also easier to seamlessly change frequency without discontinuities if all you're doing is changing the phase increment.As I already explained I used the unit circle rotation method some years ago on M4F, and showed you a working example I'd done with it.It's horses for courses. Both methods are valid. I'm not sure why you're so fixated on it TBH, other than engineers love trying to score points ;-)Edit:I'll add that I was sceptical about the dsPIC33A series: I couldn't see why they'd invest all that effort into developing a proprietary core. However now I've used it over the past few months, I can see why. It combines the benefits of single-cycle instructions so common in RISC architectures, while avoiding the load-and-store overhead of RISC thanks to its ability to use complex addressing modes within all ALU instructions.So you can do something like this...Code:add.l w2,[w9++],...and, if you are judicious with where the memory is for source and destination on separate buses and address generators, it will only take one cycle.In the ARM/MIPS/RISC-V load-store architecture, an equivalent this would take several instructions, although I accept that this is mitigated to some degree in that you would manipulate any algorithm solution to process on core registers rather than keep hitting memory. Irrespective, you have the load and store overhead, something you don't have with this proprietary architecture.I'll further add that the FPU coprocessor on the dsPIC33A, completely unlike the main core, most certainlyisa load-store architecture, and if you look at my solution you will see it's very much optimised for that paradigm.I originally developed this AM radio using the fixed point ALU. The challenges I faced performance-wise were around the quadrature LO, and minimising pipeline stalls. If I'd tried harder, I am sure I could've overcome them, but the lure of sin() and cos() out of the box was just to much of a treat.

author: MK14
author_rank: Super Contributor
timestamp: August 18, 2025, 07:11:21 am
content: Quote from: Howardlong on August 18, 2025, 06:38:00 amIn your video, I'm AMAZED at how much it sounds like a *REAL* radio (obviously, what you have done is a REAL radio, as well, technically speaking, but I suspect you know what I mean), as you manually turned the tuning knob (digital rotation sensor). With the sound changes, typical of tuning a normal radio.I've often heard those strange noise radio stations, between real/proper stations. But not really wondered too much, about their origins.Anyway, interesting/fascinating project!

author: brucehoult
author_rank: Super Contributor
timestamp: August 18, 2025, 07:15:21 am
content: Quote from: Howardlong on August 18, 2025, 06:53:07 amNot fixated in the least. But as someone who has in the past implemented transcendental functions in e.g. a GPU, and had back-and-forth with the CPU designers about what I'd like them to implement in hardware, and at other times been part of the team specifying the instruction included in a vector instruction set (and I pushed for reciprocal estimate and reciprocal square root estimate) I am curious how much accuracy a microcontroller gets in sine and cosine instructions in four clock cycles. The internet doesn't seem to want to say. I imagine there's a smallish table, maybe followed by a linear interpolation, and almost certainly followed by a round of Newton-Raphson -- I don't think there can be time for more than one.

author: RoGeorge
author_rank: Super Contributor
timestamp: August 18, 2025, 07:27:50 am
content: A dsPIC to make an AM radio? OK, but a 555 would have sufficed.No software, and with a speaker amplifier included in the same 555.AM Radio using 555 timer ICTubeTimeUS

author: Howardlong
author_rank: Super Contributor
timestamp: August 18, 2025, 08:01:35 am
content: Quote from: brucehoult on August 18, 2025, 07:15:21 amIf you are smart with the instruction pipeline, you can make it use up only 1 effective cycle.FWIW, it will not surprise you that I originally tested the entire algorithm natively on x86, and compared the results in great detail when I was debugging the instruction level. Even with the sin() and cos() right in the core of this algorithm, and the cumulative differences one might imagine I never noticed anything untoward other than in the IEEE 754 renderings in the debugger. (There's a crappy feature in MPLAB X where non-memory mapped registers including the FPU won't show in IEEE 754, so you have to write them to RAM and view them there, a right royal PITA when you're debugging down at that level).In x86, of course sin() and cos() are double precision. The FPU on the dsPIC33AK, although it offers double precision for most things, sin() and cos() are only single precision.Anyway, to satisfy your curiosity, here is a comparison.Code:for (float f = 0.0F; f < M_PI * 2.0f; f += 0.2f){printf("\r\nPhi=%f, sin(Phi)=%+12.8f, cos(Phi)=%+12.8f",f,(float)sin(f),(float)cos(f));}33ak128mc102_018_SinCos.zip(8.97 kB - downloaded 13 times.)sincos001.VS.zip(1297.02 kB - downloaded 9 times.)

author: Howardlong
author_rank: Super Contributor
timestamp: August 18, 2025, 08:21:26 am
content: Quote from: MK14 on August 18, 2025, 07:11:21 amMaybe it's the Spinal Tap amp, it does go up to 11, you know ;-)

author: MK14
author_rank: Super Contributor
timestamp: August 18, 2025, 09:40:19 am
content: Quote from: brucehoult on August 18, 2025, 07:15:21 amMaybe there is one or more customers, who for their application(s). Need very fast, real-time single precision floating-point SIN/COS calculations. Making it worth Microchips time and silicon chip area. To implement very fast SIN/COS calculations?IIRC, some of ST's MCU's, have something similar, but less capable (fewer bits?). Called something on the lines of a name-of-algorithm (CORDIC accelerator?).Edit:App note about it here (for stuff like motor control, apparently):https://www.st.com/resource/en/application_note/an5888-getting-started-with-the-cordic-accelerator-using-stellar-e-stmicroelectronics.pdf

author: brucehoult
author_rank: Super Contributor
timestamp: August 18, 2025, 09:40:40 am
content: Quote from: Howardlong on August 18, 2025, 06:53:07 amNothing is for free. If it's doing all that stuff in one clock cycle then all else being equal it will have to be a long clock cycle.And, sure enough, I see that dsPIC33A is limited to 200 MHz, while 200 MHz Arm and RISC-V are much cheaper, and dsPIC33A price will get you 700 MHz or 1000 MHz elsewhere.

author: chilternview
author_rank: Frequent Contributor
timestamp: August 18, 2025, 09:53:37 am
content: Quote from: Howardlong on August 17, 2025, 06:34:42 pmAmazing. Well done that man!

author: Howardlong
author_rank: Super Contributor
timestamp: August 18, 2025, 04:03:07 pm
content: Quote from: brucehoult on August 18, 2025, 09:40:40 amI don’t think I claimed anything otherwise.You’ve missed the point again about the on chip peripherals. Adding 40MSa/s ADCs, opamps, DACs etc isn’t making your bargain basement chip cost effective against a $1.30 dsPIC33A with all those already on chip.Also, good luck finding your 700 and 1000MHz ARM and RISC-V running at under 70mA with peripherals enabled.I have practical experience of most of the current Cortex M cores including M4, M7, and M33, all with FPUs, and dsPiC33A. As I already stated, I was sceptical regarding the dsPIC33A initially, particularly over the proprietary core, but now I’ve used them over the past few months, I see that there are valid reasons to use them in unconnected scenarios.The dsPIC33A series will be useless on its own if you want USB or networking.It’s a case of horses for courses.There are many valid options here, I just presented this one on the basis that it’s the first time I’ve been aware of a single chip MCU solution capable of antenna on one pin, audio out on another.Today, I also added a push-pull H-bridge PWM output with the on-chip high speed PWM peripheral to directly drive headphones without the need for an active amplifier.

author: MK14
author_rank: Super Contributor
timestamp: August 18, 2025, 05:28:03 pm
content: Quote from: Howardlong on August 18, 2025, 04:03:07 pmI very much agree with you. For many real-time embedded applications, even small or hobby ones. It's the quality and capabilities of the peripheral set, that really matters.But, on another note, I have to ask?In the (hopefully distant) past. Microchip, and hence PIC's, had a bad reputation, for releasing MCUs, with tons of problematic faults (errata), which weren't necessarily fixed, at least not quickly.On the other hand, they would keep their chips available for extremely long periods of time, which was good, and there were many other benefits.Are they over things like that (problematic/excessive errata), these days?Finally, a question about setting up the PWM's?How do you configure them for 110% duty-cycle, for when the headphone wearer, has requested, maximum volume, level 11?

author: Howardlong
author_rank: Super Contributor
timestamp: August 18, 2025, 05:53:16 pm
content: Quote from: MK14 on August 18, 2025, 05:28:03 pmThe silicon’s not that bad, although you do have to check the errata. There is one in this project to do with sign extending ADC results not working that meant I have to deal with it in software.There is an undocumented feature with the ADC on this chip where it generates more than one trigger for each final conversion when using oversampling that I worked around using the same trigger that triggers the conversion, rather than the ADC’s conversion complete trigger.Both of these are fixed in the latest dsPiC33A family released a couple of months ago… although they’ve managed to add a new one on the DAC which now has limited range. That is one reason why I used this slightly older chip, the other being its reduced pincount that's not available on the newly released devices.Perhaps the bad rap comes from about 12 years ago. Microchip released the PIC32MZ EC family, with high speed ADCs. It took them about 18 months to finally accept that the ADCs were completely f***ed, while repeatedly telling us they were working on a workaround. I won’t lie, I felt shafted, as I’d invested a lot of resources in the device for a product. I switched to NXP’s M4F line up for a while as a result.Thankfully, the PIC32 MZ family they released about three years after the EC family has a completely different high speed ADC that works.But that’s not the end of the PIC32 MZ story. More recently, they did a process change and managed to regress these devices’ performance, in that you had to add an additional wait state when running from flash at full speed. Without that additional wait state, very occasionally new devices would trap. Now although it was only about a 2% reduction in practical performance drop, it meant that the gold release you had for production runs needed to be changed and regression tested. But the very nature of the regression was that you might not know about it until your product was already in the field.I don’t think Microchip are any worse than anyone else these days, although I wish they would distribute bulletins for these problems actively, rather than being passive and expecting us to discover these nee issues retrospectively.QuoteYes, I can set the duty cycle to 110% for that full metal overdrive sound to accompany the pink torpedo crescendo.

author: MK14
author_rank: Super Contributor
timestamp: August 18, 2025, 06:48:31 pm
content: Quote from: Howardlong on August 18, 2025, 05:53:16 pmThat sounds good.The unfortunate reality, is that MCUs have their issues, so having some (errata), which they are hopefully going to fix, at least in some cases. Is quietly reassuring.As you said above, in the past, some of the errata, such as the very significantly problematic ADC, were potentially a show stopper.They seem interesting MCUs, for some applications. I like the look of them. The clock frequency of 200 MHz, up to 64 kB of RAM and up to 512 kB of Flash, are enough for many applications, that would suit a decent peripheral set.Also, the fact you have been able to successfully make your working AM radio, from (just about) only this MCU. Is a testament to the quality of its ADC, DAC and some of its other functionality.Otherwise, it probably wouldn't have worked at all, or could have sounded rather distorted and had other problems, with it.

author: brucehoult
author_rank: Super Contributor
timestamp: August 18, 2025, 10:47:49 pm
content: Quote from: Howardlong on August 18, 2025, 04:03:07 pmI haven't missed any point. I don't know why you are so combative here. Of course it's nice to have such peripherals.At $1.30, isn't it the dsPIC33A that is bargin basement?QuoteA whole Milk-V Duo SBC (I paid $3, they seem to be $5 now) with 1.0 GHz 64 bit core idles at 60mA after boot, around 90mA when working hard, so you could get a reasonable CPU load at 70mA.I just checked with the following code and using the IEEE-compliant standard routines in glibc it runs the following test program at around 100ns per iteration, so if you've getting sin and cos in 4 cycles at 200 MHz (80ns) then that's indeed pretty nice. All the more so if you can pipeline a new one every 20ns.As I said before, I'd be very curious to know what precision it gives. It doesn't appear to be documented, at least that I can quickly find. I'm sure it won't be IEEE-compliant, but then 10 or 12 or 16 bits is probably more than enough for its applications.Code:#include <stdio.h>#include <math.h>int main() {float t = 0, a = 0, inc = 0.01;for (int i=0; i<1000000000; ++i){t += sinf(a);a += inc;}printf("%f\n", t);return 0;}My x86 machine (i9-13900HX, 5.4 GHz) does that at 3.25ns per loop. M1 Mac (3.2 GHz) 2.5ns. My fastest RISC-V SBC is 18.7ns per loop, but it's a lot more expensive than the Duo, which is an awesome Linux machine for $5. They all print exactly the same result, btw, -2097152.000000, since they are all IEEE-754 compliant.QuoteYes, and this is very cool, no question. There are all kinds of niches to be filled.

author: brucehoult
author_rank: Super Contributor
timestamp: August 19, 2025, 04:11:58 am
content: Ohh, the dsPIC33a manual doesn't give a specification for how accurate sin and cos are, but it does give an example for each.For sin: 0x3F492492 (0.78571427) -> 0x3F351398 (0.7073302) Most accurate value in single float is 0x3f351399. Error 3.91e-8For cosine: 0x4016DB6E (2.357143) -> 0xBF3530E2 (-0.70777714) Most accurate value in single float is 0xbf3530e1. Error 3.46e-8So it's pretty good. More than good enough for any physical purpose.

author: Howardlong
author_rank: Super Contributor
timestamp: August 19, 2025, 08:46:25 am
content: Quote from: brucehoult on August 18, 2025, 10:47:49 pmPerhaps you missed the tests that I conducted to address your curiosity inpost #13?QuoteWe got there in the end! ;-)

author: Howardlong
author_rank: Super Contributor
timestamp: August 19, 2025, 08:57:58 am
content: Quote from: MK14 on August 18, 2025, 06:48:31 pmMy wish list for future products:o Dual core (possibly asymmetric, perhaps a low power core to do UI bits and bobs)o USB HSo NetworkingQuoteEspecially considering this was done on breadboard.I had to limit the update rate on the LCD to 10Hz because the I2C lines cause interference. You can hear the 10Hz clicking it at 6:25-6:31, over the "feature" signal at 144kHz when the AGC gain is high. On a properly laid out PCB, this should disappear.

author: brucehoult
author_rank: Super Contributor
timestamp: August 19, 2025, 10:34:04 am
content: Quote from: Howardlong on August 19, 2025, 08:46:25 amOh! Yes.The comment has been edited after posting. I suspect I must have read it before the edit that added the tests. Edited comments don't trigger "Show new replies to your posts" and when someone else does add more comments the window scrolls to them.QuoteWe have always been there. As someone unfamiliar with the field of DSPs and their algorithms -- the closest I've is GPUs, which also sacrifice full IEEE precision for speed -- I'm seeking to clarify things and learn from the master.

author: tszaboo
author_rank: Super Contributor
timestamp: August 19, 2025, 10:52:53 am
content: Quote from: Howardlong on August 18, 2025, 05:53:16 pmI used dsPIC some 15 years ago, and I ended up regretting it.Basically it had a fast ADC but there was not enough speed on the MCU to do anything remotely useful with the high sample rate, not to calculate, downsample or to send it out on a parrallel port. So it was more like a low latency ADC, not a fast ADC.What samplerate can you actually reach on this? Can you maybe use that 40 MSPS ADC samples to replace an RF downmixer for example? Or calculate with dithering, low pass filtering and decimating a higher resolution sample? Is the core fast enough to do this?

author: eliocor
author_rank: Unknown
timestamp: August 19, 2025, 01:58:41 pm
content: maybe it can be of some interest (different approach/micro):https://www.i2phd.org/armradio/index.html

author: UnijunctionTransistor
author_rank: Frequent Contributor
timestamp: August 19, 2025, 02:20:58 pm
content: We have come a long way from the galena crystal and cat whisker radio.

author: Howardlong
author_rank: Super Contributor
timestamp: August 19, 2025, 02:24:49 pm
content: Quote from: tszaboo on August 19, 2025, 10:52:53 amThe devil is in the details. You can get 40MSa/s, but I've only ever achieved it in bursts of samples, not with constant streaming, with or without oversampling. The fastest I've achieved with continuous streaming is 32MSa/s but I had to interleave two ADCs. With a single ADC, the fastest continuous I've achieved is 20MSa/s, although I'm aware that others have claimed over 25MSa/s.In this application, I am running a single ADC at 16MSa/s, and use the hardware oversampling feature to give 4MSa/s to the software, using DMA to batch up into 128 samples at a time. This comfortably covers the RF spectrum from DC up to beyond the end of Medium Wave.The hardware oversampling feature includes filtering itself, so analogue front end filtering requirements are greatly relaxed as a result: I rely on the opamp's own limitations to deal with that.The quadrature LO, quadrature RF downmixing, CIC low pass filter and decimation by 128 is being done at 4MSa/s, and that takes up about 70% of CPU with 100% hand-crafted assembler. After that, it switches to C, where there's a 16 tap FIR compensation filter that takes a further 4%, and then the demodulation & AGC CPU usage is 2%.You might be able to squeeze out a few more percent, but personally I can't see how much more than 5 or possibly 6MSa/s could be achieved on chip.If all you're doing is using it as a cheap ADC for streaming, that's wholly doable, but you'd need to take care choosing the device variant with enough pins on a single port to deliver the data. There is a Peripheral Trigger Generator on chip that is a programmable sequencer that can be used autonomously to generate or accept appropriate strobe signals autonomously from the CPU. It runs at up to 400MHz.

author: Howardlong
author_rank: Super Contributor
timestamp: August 19, 2025, 02:31:49 pm
content: Quote from: brucehoult on August 19, 2025, 10:34:04 amI provided the spreadsheet screenshot comparison and the code snippet that I used in the initial post, then subsequently I added the entire projects for x86 and PIC, plus the two screenshots of the raw output from both.QuoteYou've definitely come to the wrong place for that! I hadn't written a single line of assembler for this device until a couple of weeks ago. In fact, it's the most assembler I've written** for a single project for about 35 years, when I wrote graphics device drivers for the early Windows releases.** Edit: Upon reflection, I did write a Z80 floating point library around 1993. I am sure that was substantially bigger task than this.

author: peter-h
author_rank: Super Contributor
timestamp: August 19, 2025, 03:08:05 pm
content: This is an amazing project!So clever. I wish I knew how to do this.Some years ago I looked at doing an SDR solution for an aviation radio - basically AM, in the 100-130MHz range, but one would need to transmit alsoCurrent products are all stuffed (packed) with PCBs covered in inductors etc etc. Very very few of the existing players have managed to bring out new products in the last 20-30 years, and all new stuff is still, ahem, packed with PCBs.

author: UnijunctionTransistor
author_rank: Frequent Contributor
timestamp: August 19, 2025, 03:33:12 pm
content: They are not undocumented errata.Rather, Easter Eggs for the user to find, and feel the adrenaline rush that comes with it.Of course, I am being sarcastic .

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 19, 2025, 07:39:56 pm
content: Quote from: Howardlong on August 18, 2025, 08:01:35 amImpressive work!I wonder how ‘poor’ the sin and cos can be, until it degrades as an AM radio ?Since everything comes from a 12b ADC that’s at best one part in 4000.

author: Howardlong
author_rank: Super Contributor
timestamp: August 19, 2025, 08:22:00 pm
content: Quote from: eliocor on August 19, 2025, 01:58:41 pmCoincidentally I came across that today myself. Bizarrely the rationale for my project was originally for an LF time receiver for MSF, DCF, WWVB etc, which his project easily covers, as it covers up to 900kHz. This suggests a sampling rate of about 2MSa/s. There’s also quite a bit of discrete jiggery pokery on the front end such as an rRF amplifier and low pass filter that I managed to avoid thanks to the integrated opamp and oversampling ADC.The author, I2PHD, has been around in SDR for a very long time, he’s a bit of a legend and certainly knows his stuff.There’s also a Japanese fella who built an FM broadcast band receiver made with an LPC4370 that relies either on very heavy subsampling (or a downconverter that’s not disclosed). The actual ADC sample rate is only 10MSa/s, although that is still impressive work to get those samples mixed and downconverted on a 204MHz M4F core. The author uses a lookup table for sin/cos with a phase NCO. As far as I could tell either it’s not very frequency agile, or it’ll be chock full of images. There are a few undisclosed “cheats” going on to make it work for the video! ;-)It’s always interesting to see others’ approaches.

author: Howardlong
author_rank: Super Contributor
timestamp: August 19, 2025, 08:55:05 pm
content: Quote from: peter-h on August 19, 2025, 03:08:05 pmAviation is very risk averse: I don’t know if it’s still the case, but ten years ago new hand held transceivers from the usual players were only just starting to use Li-ion batteries: I think I bought the first one to come out, an Icom A24E. The problem with the NiCd based transceivers was that they were always flat when you wanted them. I still keep one in my flight bag as a matter of course after I found myself squawking 7600 one day with a failed audio panel.Occasionally I’ve looked at a 10MHz span within the voice section of the aviation VHF band from 118MHz to 137MHz on an SDR, there’s always something going on.I’ll make one comment if you’re interested in understanding how SDR works to a level where you can have a gomyourself, then the bible of DSP is Rick Lyons’ Understanding Digital Signal Processing. While it’s not a “for dummies” book, and it doesn’t exclusively cover SDR, all the tricks are in there for practical implementation. Most importantly, it’s a book for engineers, not academics. Somewhat counterintuitively, the really juicy bits when it comes to practical implementations are in the very last chapter, but the foundations are in the earlier chapters.Some of Lyons’ book is online, such as hisexplanation of quadrature signals, the backbone of SDR.

author: peter-h
author_rank: Super Contributor
timestamp: August 20, 2025, 11:03:58 am
content: My problem is that I was always rubbish at maths

author: MK14
author_rank: Super Contributor
timestamp: August 20, 2025, 12:13:02 pm
content: Quote from: Howardlong on August 19, 2025, 08:57:58 amIf you look at the two new families:The dsPIC33AK512MPS Family, Designed for power conversion applicationsAnd the dsPIC33AK512MC Family, Optimized for multi-motor control and complex embedded applications, offering a cost-effective solution for various industrial applications.Multiple sources, but one of them is:https://www.microchip.com/en-us/about/news-releases/products/microchip-enhances-digital-signal-controller-lineup-with-industryThey do seem to be aiming for gaps in the market (someone said niche, in an earlier post), rather than trying to make an all singing and dancing, general purpose chip (MCU). Which probably would then have been another, somewhat generic Arm/Risc-V etc MCU, Jack of all trades, Master of NONE.Some rather impressive specifications, in places, such as the 78 ps PWM resolution.From link above:QuoteWhich is rather amazing.I wonder how they do it. Presumably some kind of tuned/characterized gate (or similar) delay design. But perhaps one of the other numerous techniques, for doing it. I wonder how 78 ps, compares to the basic gate propagation delay?I think you managed to do it on a breadboard (stating the obvious to most people on this forum), because it was relatively low frequency, and didn't attempt to do the amplification on the breadboard itself, directly. Otherwise feedback oscillations, could have dominated.Even so, given that the signal, is not only analogue, but doesn't even have the partial protection that FM gives, to noise. It is still very impressive that the breadboard isn't picking up enough noise, to mess around with things. E.g. Mains hum or other stronger radio stations, from messing things up etc.

author: peter-h
author_rank: Super Contributor
timestamp: August 20, 2025, 01:21:28 pm
content: Could this have been done with a STM32F417?It does a sinf() (that is a single float, using hardware floats) in under 2us.

author: Howardlong
author_rank: Super Contributor
timestamp: August 20, 2025, 03:41:30 pm
content: Quote from: peter-h on August 20, 2025, 01:21:28 pmProbably you’d use a different method. In 2us, this has already processed 8 sin() and 8 cos() as it samples at 4MSa/s.The method I used on the Cortex M4F ten years or so ago was the rotating phasor method mentioned earlier in this thread. I believe that is also the method that I2PHD uses in his ARM Radiodescribed hereand alsodescribed hereas the “Rader/Gold” method in the appendix, slightly rearranged and simplified with unity gain.

author: djacobow
author_rank: Super Contributor
timestamp: August 20, 2025, 03:47:49 pm
content: This is nothing! I've built many AM radio receivers accidentally when I was trying to build something else. :-)

author: Howardlong
author_rank: Super Contributor
timestamp: August 20, 2025, 09:23:36 pm
content: Quote from: djacobow on August 20, 2025, 03:47:49 pmAin't that the truth!When I was about 10 or 11, my uncle gave me an audio amplifier board for me to fiddle with. That picked up everything! As you can imagine, I was pretty confused, especially considering it had no ferrite rod or any obvious antenna.Years later, of course it dawns on me that everything's an antenna.

author: Howardlong
author_rank: Super Contributor
timestamp: August 24, 2025, 08:36:55 pm
content: Quote from: MK14 on August 20, 2025, 12:13:02 pmI forgot to answer this question.I haven't used the "fine edge placement" in the 2nd gen dsPIC33AK but I have on other dsPIC33 devices which are based on delay lines with fixed delays, which dictates the PWM clock speed. On the dsPIC33AK512 MPS/MC 5xx/2xx families it runs at 16x the speed of the base PWM, which in fine edge mode must be between 300MHz to 800MHz, giving 72ps edge placement at 800MHz x 16. This brings with it some limitations when you operate it in fine edge placement mode that aren't present in "normal" mode, most obvious being that the period is tied to the base clock, sofrequency resolutionisn't 78ps, butduty cycle resolutionis. Furthermore, if fine edge mode, there is a minimum pulse width of 16 units, or 1.25ns. You can't have it at zero, perhaps this can be fudged with the dead time control, but note I haven't tried it.For the typical use cases it's designed for such as SMPS and motor control, this isn't a problem, but for some applications, for example precision NCOs, it might be.The technology reminds me somewhat ofTek's MagniVuthat provides timing resolution down to 20ps on some of its LAs and scopes.What I can say now that I've had some time to evaluate these second generation newer chips is that the power draw is half of that of the first generation, due to a buck regulator for Vddcore rather than the linear regulator in the first generator. In my own measurements, at 200MHz, this reduces 3.3V current down from a smidgin over 50mA to a tad under 25mA. I didn't have any peripherals running, but some of their clocks were configured.

author: MK14
author_rank: Super Contributor
timestamp: August 26, 2025, 09:01:07 am
content: Quote from: Howardlong on August 24, 2025, 08:36:55 pmSorry, for my last two responses, taking longer than I'd have liked.Thanks for the interesting explanation, on how the fine edge PWM mode works.It sounds like they moved to a new process node for those MCUs. Hence the power consumption halving, flash memory (doubling?) size increases etc.It can be annoying, with PWM's (in fine edge mode) which don't go to zero.Quote from: Howardlong on August 24, 2025, 08:36:55 pmI think that nails it. Consider a back of envelope, estimation of the basic gate delay time. Given that many IC processes achieve, at least **1.333 GHz, when it has a modern Arm/RISC-V implementation. Then taking a (very, very approximate) rule of thumb, that it is at least ten gate delays per clock cycle.Then a clock frequency of 1.333 GHz = 750 ps (clock period) / 10 (gate delays per clock cycle) = 75 ps.**Two disclaimers. Firstly, yes, I did fiddle with the figures, to get it close to the 78 ps.Secondly, MCUs are lower clocked, for various reasons, including (usually) shorter pipelines, stability, wide-temperature range, low power consumption etc. Also, they are usually on older process nodes, that don't support the fastest clock speeds.

author: Howardlong
author_rank: Super Contributor
timestamp: August 27, 2025, 08:17:57 pm
content: I think the dramatic lower power consumption is due to the on-chip buck regulator on the core, rather than a linear regulator in the first gen devices.This buck regulator has potential noise issues in the analogue domain, and there's no documentation as to whether it's possible to replace it with a linear regulator. The buck regulator runs at around 3MHz.FWIW, the key differentiators between the MPS and MC variants in the newly-released family are:o Fine edge placement only on MPS (I only discovered this today, after attempting to use it)o MPS has a crypto acceleratoro 8 DACs & comparators on MPS vs 4 each on MCo MPS also available in 128 pin package. All are available in 48, 64, 80 and 100 pin packages.

author: MK14
author_rank: Super Contributor
timestamp: August 27, 2025, 09:54:40 pm
content: Quote from: Howardlong on August 27, 2025, 08:17:57 pmThat makes a lot of sense, changing between linear and switching regulators, dramatically reducing the power consumption.I guess the MPS needs the fine edge placement, so that high efficiency, (relatively) high frequency converters, such as GaN or SiC, can still have relatively fine control of the PWM ratio.Why the crypto accelerator, would be especially on the MPS, is not immediately obvious. But I wonder if particular customer(s) and/or applications, make the MPS need it.Perhaps the automotive people, want to *lock* individual controller units (ECUs), so that only authorized distributors can deal with it. Hence the apparently advanced crypto unit features. Their thinking might be, that multiple components within the controller unit, need to be *locked*, to minimize the risk of profits/safety/regulations, being hurt by attempts to fix the controller units, at a later time.Alternatively, it might be to enhance the security of the firmware, against being copied by competitors.But, I'm only making educated guesses, so could easily be wrong.

author: BrianHG
author_rank: Super Contributor
timestamp: August 28, 2025, 12:00:25 am
content: I'm curious, if you were to place your radio next to an all analog AM radio, how much delay would your DSPIC audio output be compared to the analog receiver.I once heard a cell phone with a FM radio having something like a 2 second delay between its audio and a normal analog FM radio. Really annoying.

author: MikeK
author_rank: Super Contributor
timestamp: August 28, 2025, 05:31:55 pm
content: Thanks for posting this, Howard. Would you happen to have a schematic for it?

author: Howardlong
author_rank: Super Contributor
timestamp: August 28, 2025, 09:15:22 pm
content: Quote from: BrianHG on August 28, 2025, 12:00:25 amThe ADC has a 128 sample buffer delay, so at 4MSa/s that is 32us.Then there is a processing delay of about 25us before a sample is ready for the DAC.However, DAC samples aren’t sent until there are 128 ready, plus a 16 tap FIR filter, so that's about 4.6ms.So the total delay in this implementation is under 5ms.This DAC buffer delay could be substantially reduced, the 128 DAC sample buffer size is totally arbitrary, unlike the ADC buffer size which is closely related to the CIC decimation rate. The largest determining factor then would be the FIR compensation filter length. So if you really wanted to, you could get the total delay down to about 300us.

author: Howardlong
author_rank: Super Contributor
timestamp: August 28, 2025, 09:34:45 pm
content: Quote from: MikeK on August 28, 2025, 05:31:55 pmTake a look at the comments in the main.c, hopefully I captured everything there, what all the pins are used for and any passive components above and beyond decoupling.I never did a formal schematic for it, I just built it incrementally over a couple of weeks, almost all of that tome was working on optimising the downsampler filtering: this is still a work in progress.For example, already I completely rewrote the quadrature encoder code using my tried and tested algorithm that I originally wrote for PIC16. This supports multiple quadrature encoders simultaneously and avoids the need for any external passives. I have implemented an H Bridge PWM to directly drive a loudspeaker in Class D, it works surprisingly well, and is certainly loud enough, but I do use a couple of tricks to make that happen. I’m also porting it to the newer second generation devices. I’ve been working on using one of the opamps as a transimpedance amplifier so you can use one of those to use a cheap AM loop antenna, which works, but needs more work as it’s not as sensitive as I’d like. I’ve also taken the opportunity to refactor the main.c code into multiple source files.