[BUG]V2.1.7 Sun Pro

[F6Bernie]

Hi all ! I've installed the V2.1.7 and there's no sound at all (same configuration audio than usual), the panafall display is extremely slow and the receiver seems completely deaf (quite no signal even if I'm listening the 40 mtrs which is very busy at this time of the day...).

If you need other screenshots, just ask ;)
73' Bernie

[jimallen60]

Both my son that has a SunDDR2 Pro and I am seeing the same as Bernie,

Garbled heavy pulsing, clearly an issue with the changes. Back when I purchase this and had the oppertunity to talk with the manufacture, they stated that the Pro was the same radio just not the high power section of the transmitter.

Jim
W4JEA

[s-car-go]

I’m not getting any audio from the front‑panel headphone jack when using Artemis. The hardware itself is fine — if I run the EE SDR3 software, the headphone output works normally.

My setup uses an external audio mixer connected directly to the mic and headphone jacks so I can avoid the high latency that comes from routing audio through a Windows VAC. Because of that, I rely on the radio’s internal audio path and the front‑panel headphone amplifier.

With Artemis, it appears the headphone audio amplifiers may be disabled. In Thetis (with Apache Labs radios), there is a specific setting that turns the hardware audio amps on or off. I haven’t been able to find an equivalent control anywhere in Artemis.

Is there a setting I’m missing, or does Artemis currently not expose the hardware headphone‑amp enable function?

Dave... WB5QFZ

[ea5ccy]

I have the same problem with my SunSDR2 Pro, using Artemis 2.1.7 running under windows 10. Now the sample rate it's ok but I haven't sound and the panafall go very slow.

EA5CCY - Pedro

[SQ5OMO]

I have the same problem - either there is no sound and when I manage to change something, it is distorted and the program closes, it crashes

[SQ5OMO]

Setup.2026-05-11.15-32-05.mp4

[jimallen60]

Has anyone had any luck getting this version to pass audio? I have been out of town for a few days and just attempted to get this working. When I set my VAC to ASIO, I was able to get the speactrum and waterfall appearing normal, however no luck with any audio. I noticed the mouse pointer hovering over the Enable VAC 1 and tried toggling that on and off.

Also how do you widen the FFT display to show more of the spectrum.

I'm back for the next two weeks and would love to assist however needed.

73
Jim
W4JEA

[s-car-go]

You can vary the width of the spectrum being displayed by moving the "zoom" slider located at the bottom of the waterfall located just right of center. Also there are some pre-set magnifications there also.

[jimallen60]

I have hit the wall attempting to get 2.1.7 audio on my SunSDR2 Pro. Spectrum display has the full range, All is appearing to be stable except no audio. I attempted to use ASIO as suggested, Yet can not get any audio. I also installed VoiceMeeter Bannana in an attempt to get the ASIO audio, It appers the app is not sending of receiving any audio to the PC.

Any suggestions.

73
Jim
W4JEA

[kk68]

Hi all — sorry about the broken v2.1.7 and the long silence. I've been out of town traveling for the past couple of weeks, so the back-and-forth on this regression went unanswered far longer than it should have. Apologies for the friction.

v2.1.8 is up — it reverts the v2.1.7 PRO native-rate change exactly:

📦 https://github.com/kk68/ArtemisSDR/releases/tag/v2.1.8

PRO RX is back at 39,062.5 Hz native with the 384 kHz upsample stage feeding WDSP — same as v2.1.6. Panadapter span is back to ~20 kHz around the tuned frequency (narrower than EESDR3 at higher rates), but audio works. Bernie, Jim, Pedro, SQ5OMO — please install v2.1.8 and confirm RX is back to normal.

What went wrong. Pedro's "the sample rate it's ok but I haven't sound" was the diagnostic clue. The radio accepted our 0x32 rate-set command (which is what the DX uses for 312500), and the spectrum did render at a wider bandwidth — so the rate change reached the radio. But downstream audio was broken. The most likely explanation is that the rate-code lookup table differs between DX and PRO: 0x32 on DX produces 312500 Hz cleanly, but on PRO it appears to command a substantially higher rate (the SunSDR2 PRO is documented to support up to 1.25 MHz native) — the downstream WDSP RX channel was configured for 312500 Hz and could not keep up with the actual incoming stream. That matches everything reported: wide spectrum (consistent with a higher-than-expected wire rate), no audio, slow panadapter, occasional crashes.

What v2.1.8 keeps from v2.1.7. The cmASIO Setup UX fix (dropdowns unlocked, Disable feedback) and the meter skin/asset path fix (Bernie's #45) are unchanged and still shipped. Those were independent of the PRO rate change.

On Dave's question (WB5QFZ, front-panel headphone amp enable) — that's a separate feature gap. Artemis doesn't currently expose a hardware headphone-amp enable for the SunSDR family the way upstream Thetis does for the Anan-family hardware. It's a real request and worth its own issue if you want to file it separately; I'll track it as wishlist alongside the rest of the SunSDR-specific feature gaps (front-panel mic/phones routing per issue #17 is in a similar space).

For the future. Lifting the PRO rate properly will need a wire capture from a willing tester comparing EESDR3 PRO at 39062.5 Hz vs the higher rates — that gives us the actual rate-code byte the radio expects, instead of guessing. If anyone on this thread has Wireshark + EESDR3 + a half hour, the captures would unblock another attempt safely. Until then, PRO stays at 39062.5 native.

Heads up: I'm less involved with Artemis day-to-day right now while work / travel commitments take priority, so follow-up turnaround on remaining items will stay slower than the recent cycle. I'll still see and respond to reports here.

Thank you all for the patience and the careful regression reports — they made the diagnosis straightforward once I was back at a keyboard.

73, Kosta

[F6Bernie]

Hi Kosta, nice to read you again !
You said :"For the future. Lifting the PRO rate properly will need a wire capture from a willing tester comparing EESDR3 PRO at 39062.5 Hz vs the higher rates — that gives us the actual rate-code byte the radio expects, instead of guessing. If anyone on this thread has Wireshark + EESDR3 + a half hour, the captures would unblock another attempt safely"
Well I downloaded (and installed) WireSharck but it seems a bit tricky to me (my computers programs skills are pretty poor).
So if you can give me a short tutorial (screenshots?) to reach what you need, I'll try to do it... I made a test with the program (capturing from Ethernet 5) as shown under :

FYI, my first page shows this :

73' Bernie

[kk68]

Hi Bernie — thank you genuinely for stepping up, and apologies right up front for putting you through the Wireshark download for what's about to turn into a non-starter on my side.

Owing you honest math on what doing this right would actually take, and what I can realistically commit to:

The full chain. Wire captures from EESDR3 at each of the four PRO IQ rates (39062.5 / 78125 / 156250 / 312500 Hz, and any higher rate if the radio exposes it) — that's the input. Then I have to decode each one to find the rate-set command byte, build a rate-code lookup table, modify Artemis to use the correct codes, ship a v2.1.9, have you test it, iterate if the first attempt is off, and possibly do this a second or third round before it lands cleanly. The captures themselves are 30 minutes of your time at most. The analysis and iterate-with-you side of it is several focused hours of mine, spread across multiple round-trips.

Where I actually am right now. Work commitments + travel are eating most of my evenings and weekends. I'm light on the kind of focused stretches this needs. v2.1.7 was already a misfire from underestimating the protocol risk; doing this one badly a second time would be worse than not doing it at all.

The honest decision. I'm going to leave the PRO native-rate lift parked as a known limitation against v2.1.8. Your PRO stays at 39062.5 Hz native with the ~20 kHz panadapter span — narrower than EESDR3 at the higher rates, but RX audio works reliably. We revisit when (a) someone with a SunSDR2 PRO on their actual bench takes this on as a focused project, or (b) I have a stretch of clear bandwidth myself, whichever comes first.

Your Wireshark install isn't wasted. Wireshark is a genuinely useful tool to have around for any future networked-radio debugging. And if a future contributor picks up the rate-lift work and asks you for captures, your offer here is still valid — you'd be helping them with the same artifact. I just don't want to ask you for it under my watch when I can't responsibly do my half of the loop.

Thank you again for jumping in. Sometimes the right answer is "not now" rather than dragging both of us through a partial attempt.

73, Kosta

[F6Bernie]

OK Kosta, no problem at all ! Even if i'm not good with all these applications, I can imagine how hard it should be to develop Artemis ! Thank you for the great job you did and I'll follow you on these lists to see what's coming up ;)
Greetings from France !
Bernie

[jfrancis42]

Hey folks — Jeff, N0GQ here. I've been doing my own from-scratch SunSDR2 PRO project (pure Python, talks straight to the radio, no ExpertSDR3), and I've got a real PRO on the bench with a bunch of EESDR3 wire captures. I think I have the missing piece for the rate problem that bit v2.1.7.

Short version: the eight 0x14 per-channel rate-code words are not the rate selector on the PRO. They're fixed formatting — they stay 0x14 at every rate. That's why swapping them to the DX's 0x32 broke RX (Bernie's "no sound, deaf receiver, super-slow panafall"): it corrupts the state-sync template without actually changing the rate.

The real selector is a rate index sitting in the STATE_SYNC (0x01) packet at byte offsets 56 and 58 — two little-endian uint16 fields that carry the same value:

index	rate
0	39062.5 Hz
1	78125 Hz
2	156250 Hz
3	312500 Hz

How I nailed it down: captured EESDR3 stepping the PRO 39 → 78 → 156 → 312 → back to 39 kHz, and that index field cycled 0 → 1 → 2 → 3 → 0 in perfect lockstep, while the 0x14 words never moved. When I set the index myself and leave the 0x14 words alone, the PRO streams at exactly the rate I ask for. FT8 decodes clean at 312500 on my end.

So the DX-vs-PRO difference isn't "same field, different code" — it's a different field entirely. The DX apparently keys off the rate-code words; the PRO keys off this index and treats the 0x14 words as fixed.

One gotcha waiting on the other side once the rate actually changes: at the high rates the decimation ratio to audio gets big (~26:1 for 312.5k → 12k), and a plain FFT-based resample() will smear the tones and quietly kill FT8 decode even though the panadapter looks great. A polyphase resample (or a staged decimator) with a real anti-alias filter fixes it. Mentioning it because "rate set but no usable audio" could look like a rate bug when it's actually the resampler.

I wrote all this up (plus a few other PRO findings — DDC offset, telemetry map, front-end opcodes) here, in the same spirit you shared your work: https://github.com/jfrancis42/solsdr/blob/main/ARTEMISSDR.md

Fair warning: I don't have a Windows machine to test any of this on, or I'd have just offered you a PR. Everything here is from my own Linux tooling against a real PRO, so it's protocol-level findings rather than something I can drop straight into the Artemis build. Happy to grab more captures if it'd help — I've got the PRO here and the capture rig set up. 73, Jeff N0GQ