You can use it with Windows/MAC/Linux, but you only need the Thesycon driver for Windows. Once Windows gets full support for UAC2 the driver shouldn't be necessary. Win10 does have some support. I haven't really followed it closely, but as I understand it, there is some support for playback, but not for recording.
I am not sure if the DFU protocol is documented (generally available).
I am not sure if I got this right... the Thesycon driver software is required only to make the RTX work with Windows. As a consequence, those users who don't have Windows are left in the dust when it comes to firmware updates. Really!?
It would really be good to have some other software tool that allows updating the RTX firmware without the requirement for a specific operating system (Windows in this case).
As a consequence, those users who don't have Windows are left in the dust when it comes to firmware updates. Really!?
It would really be good to have some other software tool that allows updating the RTX firmware without the requirement for a specific operating system (Windows in this case).
I'm sure we can't blame Jens/RTX for this. As far as I remember he didn't promise support for all OS's. Also if the RTX analyzer behaves like an ordinary USB audio device it should work on other OS's as an audio device.
However, DFU is another matter. If the DFU protocol is open we can just make a Python DFU loader ourself. Shouldn't be that difficult (famous last words 😀 ).
Mogens
Hi Jens,
I was able to get a laptop running Windows 8.1. The update ran on that, so I'm all up to date now.
Is it possible to write something to talk to Win7? Most applications that run on Win7 also run up to Win10.
As for windows 8.1 ... it's horrible! It should be updated to Win10 (assuming that's better)!
-Chris
I was able to get a laptop running Windows 8.1. The update ran on that, so I'm all up to date now.
Is it possible to write something to talk to Win7? Most applications that run on Win7 also run up to Win10.
As for windows 8.1 ... it's horrible! It should be updated to Win10 (assuming that's better)!
-Chris
Good that you got it working.
Win7 should normally work fine. I use Win7 both at work and at home (on my main PC). I have a laptop with Win10, but I mostly use the Win7 PC.
Win7 should normally work fine. I use Win7 both at work and at home (on my main PC). I have a laptop with Win10, but I mostly use the Win7 PC.
When time permits, I will try to see if the XMOS design can be updated using the standard USB DFU protocol.
Mogens
Mogens
Hi Jens,
My instances of Win7 Pro are all up to date for updates.
It opens the device, loads the file and when I tell it to start, it seems to hang right after it begins the update process. It's probably timing out. It fails with a memory error which I have not written down.
-Chris
My instances of Win7 Pro are all up to date for updates.
It opens the device, loads the file and when I tell it to start, it seems to hang right after it begins the update process. It's probably timing out. It fails with a memory error which I have not written down.
-Chris
I had the same problem. It went away when I added an USB hub in the connection inbetween computer and RTX 6001 😕Hi Jens,
My instances of Win7 Pro are all up to date for updates.
It opens the device, loads the file and when I tell it to start, it seems to hang right after it begins the update process. It's probably timing out. It fails with a memory error which I have not written down.
-Chris
The "-1"-sample-problem is solved for me with the new firmware. Thanks!
Next issue 😉
There seems to be an auto DC-offset correction. See the following picture, a loopback recording (lower tracks) of a "0, -FS" square wave (upper tracks).

You see that the mean value of the recording rises such that the mean is finally zero. For measurement purposes this is an unwanted "feature" for me. But I fear that is an feature of the ADC chip itself.
P.S.: settings out 0dBV, in 10dBV, DC coupled.
Next issue 😉
There seems to be an auto DC-offset correction. See the following picture, a loopback recording (lower tracks) of a "0, -FS" square wave (upper tracks).

You see that the mean value of the recording rises such that the mean is finally zero. For measurement purposes this is an unwanted "feature" for me. But I fear that is an feature of the ADC chip itself.
P.S.: settings out 0dBV, in 10dBV, DC coupled.
The ADC has a high pass filter with a 3 dB cut off at 1 Hz. This filter is enabled in this design and the 3 dB cut off is documented in the User Manual. And it cannot be disabled by the SW.
Hi Jens,
I used to have some frequency pickup close to 50 KHz. The shield modification has reduced this to a lower amplitude. The shields are doing their job it would seem.
-Chris
I used to have some frequency pickup close to 50 KHz. The shield modification has reduced this to a lower amplitude. The shields are doing their job it would seem.
-Chris
FWIW I'm having trouble with the update. In my case it seems to originate in an older firmware. I think it may be due to a different USB PID-VID when in DFU mode.
You can check that by putting the RTX into DFU mode then check the device tree in Windows. It will be under unidentified devices. Then check the VID-PID (vendor ID and Product ID which are USB product identifiers that the OS uses to load the right driver) under details => hardware ID's.
Mine reports VID 20B1 and PID 0008 which are the demo ones for XMOS. My unit is preproduction and started with the demo firmware. When operating it has the RTX VID PID.
I'm sure we will have this sorted out soon.
You can check that by putting the RTX into DFU mode then check the device tree in Windows. It will be under unidentified devices. Then check the VID-PID (vendor ID and Product ID which are USB product identifiers that the OS uses to load the right driver) under details => hardware ID's.
Mine reports VID 20B1 and PID 0008 which are the demo ones for XMOS. My unit is preproduction and started with the demo firmware. When operating it has the RTX VID PID.
I'm sure we will have this sorted out soon.
The RTX is fully USB audio compliant and works on even Android. The DFU is a special case and normally needs to be carefully managed so you don't casually "brick" the device. DFU programs are usually device/OS specific (and can be costly to get written).
The ADC has a high pass filter with a 3 dB cut off at 1 Hz. This filter is enabled in this design and the 3 dB cut off is documented in the User Manual. And it cannot be disabled by the SW.
If it can't be disabled by software, is there a hardware hack to achieve this?
If it can't be disabled by software, is there a hardware hack to achieve this?
The HPFE pin 19 of AK5394A controls the built-in high-pass filter.
There is a pin on the AK5394A that controls the filter. I'm not sure how stable the DC is on the chip and associated electronics. I'm pretty confident that it NOT be zero without adjustment and probably not stable enough to stay at zero even if adjusted. This is a different type of hardware.
All group buy units were shipped with firmware V1.10, which use the RTX VID/PID.
Demians unit is a special case. As he writes, we will have this sorted out soon.
Demians unit is a special case. As he writes, we will have this sorted out soon.
Probably, it should be easy with some unofficial support 😉
The controls are accessible via the PCB:
View attachment 675862
Looking at the AK5394A data sheet, the filter is enabled if pin 19 ("HPFE") is high, and disabled if the pin is low. Hmmm... can I just pull the HPFE pin in your photo to GND without breaking stuff or affecting performance in any other way? Jens, what are your thoughts about this?
FWIW I'm having trouble with the update. In my case it seems to originate in an older firmware. I think it may be due to a different USB PID-VID when in DFU mode.
You can check that by putting the RTX into DFU mode then check the device tree in Windows. It will be under unidentified devices. Then check the VID-PID (vendor ID and Product ID which are USB product identifiers that the OS uses to load the right driver) under details => hardware ID's.
Mine reports VID 20B1 and PID 0008 which are the demo ones for XMOS. My unit is preproduction and started with the demo firmware. When operating it has the RTX VID PID.
I'm sure we will have this sorted out soon.
Definitely, we had the same problem and with the previous v1.16 fw. It seems to be a XMOS update problem, a google search gives a lot same issues!
And now I have the same problem with the new version...
When time permits, I will try to see if the XMOS design can be updated using the standard USB DFU protocol.
Mogens
This may be helpful: What is the procedure to upgrade a USB Audio device firmware - XMOS embedded processors. Heart of XMOS technology, XCore.com
- Home
- Design & Build
- Equipment & Tools
- DIY Audio Analyzer with AK5397/AK5394A and AK4490