Below is thd chart for AD797. Plus, ad797 specified at +-5 and +-15V, and to interface it with +5V adc, RC network must be customized in order to prevent damage of the adc . What I'm driving at, thd-3 harmonics has to be present on 12 kHz thd chart.
Driving differential adc directly from single ended oscillator is also has obvious fingerprints, in strong thd-2/4 harmonics.
For myself, I feel more confident when I see all line thd2 - 11, and missing some harmonics could point on mistakes in hardware or software processing.
Attachments
"subjects involved could poll resources and hire someone"
I cannot imagine someone would be willing to code it for free. IMO it would be even difficult to find someone experienced enough who would want to contract the job.We all do, my daughter has just taken my bed while hers is kind of small....
Last edited:
It is not a good idea, because it need ~40dB of correction, plus at least 10-15dB spare margin.
The result ENOB will be too low.
In al truth, I don't see Thesyscon driving much business in the future. Windows 10 now supports natively 192KHz/24bit/2channels which pretty much covers 99% of the home market. The $$$ Thesyscon driver supports up to 8 channels, but what's the PC based market for that? OTOH, Windows 7 just went out of support, no more updates and patches, so it will go down to obsolete quickly from now on.
My secret hope is that Thesyscon will go belly up in this business unit and will open up the code (like many other software businesses did).
Nobody wants to pay for software development today; software is considered today an off the shelf commodity. Much less small businesses.
They probably wouldn’t be so gracious. They might not have a choice either after they sold at least part of the source to Microsoft. Who knows what terms the lawyers were able to extract.
high-speed transfer to Windows
If you want to transfer high-speed SPI(1.536MHz) stream into Windows, how about using Rpi as an interface device? , though I do not know Windows and Linux software at all. As long as I know, Rpi can accept 1.536MHz SPI through gpio. It's a piece of cake to convert the LVDS protocol of high-speed SAR ADC into SPI for Rpi if you have a small FPGA like xc6slx09. Can the accepted data by Rpi be transmitted to Windows PC through LAN?
If you want to transfer high-speed SPI(1.536MHz) stream into Windows, how about using Rpi as an interface device? , though I do not know Windows and Linux software at all. As long as I know, Rpi can accept 1.536MHz SPI through gpio. It's a piece of cake to convert the LVDS protocol of high-speed SAR ADC into SPI for Rpi if you have a small FPGA like xc6slx09. Can the accepted data by Rpi be transmitted to Windows PC through LAN?
Hi again ... Can I ask a question in relation to this driver topic:
Let's just for a moment assume that there is a person(s) who can program this ... Would you then be willing to pay for such a driver? And how many would you think would be willing to pay for it? And how much?
Personally I wouldn't mind paying USD 200-300 for such a driver and my "guess" would be that there could be some hundreds worldwide who could also be interested in this. Also if one e.g. could get the SAR ADC companies involved (Analog Devices, TI, Maxim, more?) may it be that they would chip in money/maybe even develop the driver to allow their products to grow "easier" in the market? It is my impression that in many cases very good products don't really grow because there is some missing link in the product's "usability chain" - and may such a driver make a difference here?
@phofman: I personally would be fine with a linux driver although it would mean that I would have to learn to use Linux. Ardour recording software - which can do 1.536 MHz when correctly set up - is mainly Linux based.
@xx3stksm: It is my impression that you are really skilled in FPGA etc. programming so I would be very interested in hearing any suggestions you may have for this. But personally I would have to add that I cannot contribute here except with a bit of money (on the 200-300 USD magnitude).
@MagicianT: Hi again ... Well, Viktor's oscillator at 12 kHz to my memory is -133 dB THD. The input signal to the LTC2380-24 is -7 dB and the "noise level" is about - 130/131 dB. I likely used +/-12 volt PSUs (batteries) if I used the AD797s. Regarding processing I cannot say if there is something in WaveSpectra but I am quite sure that the transfer from the 2380 is data only - likely with some averaging. But no processing ... We all preferred to keep things as simple as possible.
Cheers,
Jesper
Let's just for a moment assume that there is a person(s) who can program this ... Would you then be willing to pay for such a driver? And how many would you think would be willing to pay for it? And how much?
Personally I wouldn't mind paying USD 200-300 for such a driver and my "guess" would be that there could be some hundreds worldwide who could also be interested in this. Also if one e.g. could get the SAR ADC companies involved (Analog Devices, TI, Maxim, more?) may it be that they would chip in money/maybe even develop the driver to allow their products to grow "easier" in the market? It is my impression that in many cases very good products don't really grow because there is some missing link in the product's "usability chain" - and may such a driver make a difference here?
@phofman: I personally would be fine with a linux driver although it would mean that I would have to learn to use Linux. Ardour recording software - which can do 1.536 MHz when correctly set up - is mainly Linux based.
@xx3stksm: It is my impression that you are really skilled in FPGA etc. programming so I would be very interested in hearing any suggestions you may have for this. But personally I would have to add that I cannot contribute here except with a bit of money (on the 200-300 USD magnitude).
@MagicianT: Hi again ... Well, Viktor's oscillator at 12 kHz to my memory is -133 dB THD. The input signal to the LTC2380-24 is -7 dB and the "noise level" is about - 130/131 dB. I likely used +/-12 volt PSUs (batteries) if I used the AD797s. Regarding processing I cannot say if there is something in WaveSpectra but I am quite sure that the transfer from the 2380 is data only - likely with some averaging. But no processing ... We all preferred to keep things as simple as possible.
Cheers,
Jesper
About what they lied?
They never tacked about 768, but for 384 the limit is 7 channels for 24 bit, and 5 channels for 32 bit.
See attach, page 4, Table 4.
Unfortunately, XMOS's USB stack and the Thycon driver do not use High-BW Endpoint, so the transfer is limited to 65Mbit/s.
You can do whatever you want.
I tried this in practice many years ago, except the theoretical issues. And came to conclusion, that only combined processing is good - pre-processsing in analogue pre-amplifier, with simple downhill frequency response. And finally - in digital domain to get the accurate RIAA.
But instead of this, I use normal tube phono stage, without ADC and any digital processing. But this is also not for this thread
Last edited:
Well then no need for the conditional tense, use it right away - USB-audio class 2 runs just fine at 2.6MHz with stock kernel and likely much faster if the device sent multiple transactions per frame (I have already linked the test results too many times here). That 2.6MHz is just a result of samplerate/channel count/sample size combination to fill up the 65Mbps bandwidth. Could be divided to any number of channels, or be higher for just 16 bits etc.
[offtopic rant on] It is windows everybody else but you and me requires (because got voluntarily locked with lots of other expensive proprietary solutions) which have poor drivers and no basic facilities like reliable bit-perfect virtual loopback devices for chaining software tools. [offtopic rant off]
Last edited:
Honestly, I do not have such experience. Software is key part of almost any activity or physical device today and makes up substantial part of project budgets, IF some pre-existing stock solution cannot be used. All technology companies around have software developers on their payroll.
I contributed a small amount of code to some USB device class driver development for Windows, Linux, and QNX almost 10 years ago. We tested USB performance and were able to achieve similar numbers between Windows 7 and Linux at the time, measured in throughput using bulk transfers and then also interrupt and isochronous. QNX trailed both significantly. I suspect a better driver than the Thesycon can handle those kind of data rates on Windows also. RME has their own in-house driver I believe, I bet it's pretty good.
OT also but the grass is not always so green on the Linux side with drivers and configuration as well. People who can build their own kernel and modules from source generally don't have too many Windows problems either
.The unfortunate truth is that the Linux desktop will never arrive for various reasons. We'll be in a post-desktop world by then. It may very well be powered by Linux on the back-end, though. I'd love to run Linux as my only OS but too many applications are missing and I find it more advantageous to run a Debian VM on a Windows host than the reverse.
My experience mirrors yours.
Last edited:
Thank you, this is exactly what I am talking about. If the underlying technology allows, the software stack should not hold users back. I believe it would take very little for Thesycon authors to support any rate/channel/samplewidth combination the device reports all the way up to combined rate of 65Mbps (the multiple transactions per frame is a different scenario and would likely take redesigning corresponding parts of the driver). I did not do any changes to stock linux UAC2 driver and it worked right away, very likely it was never physically tested at 65Mbps before.
This speed is nothing for modern hardware (including latest ARM SBCs), USB3 runs at 5Gbps, decade-old SATA3 6Gbps, all of that easily handled by drivers in any OS.
So, since I don't see any software based (with minimal hardware) SPI to I2S conversion available, it appears the CPLD solution is the only path... so I started a few weeks ago studying Verilog. One of the most frustrating experiences I ever had... my 30 years of pro software experience is worth shite, or even worse, it's actually a hurdle to work around. Nothing seems to be familiar, other than the Verilog language syntax... I can read some basic code and figure out how it's working, but when it comes to implementing anything, I am still very far away and in the dark, struggling with the very basics of behavioral description...
The Internet is full of examples, comments, advice, boards, etc... but somehow nothing is coming together as a coherent way to approach a dgital design from scratch, starting from defining the inputs and the outputs. It's funny, If I would have to design a Moore state machine with pen and pencil, as I was educated, with a bunch of flip flops and gates, I could probably do it much faster than thinking through it's behavioral description, I suppose my brain is not wired for this (or is too old to process and digest the required information).
But I'm not ready to give up yet...
The Internet is full of examples, comments, advice, boards, etc... but somehow nothing is coming together as a coherent way to approach a dgital design from scratch, starting from defining the inputs and the outputs. It's funny, If I would have to design a Moore state machine with pen and pencil, as I was educated, with a bunch of flip flops and gates, I could probably do it much faster than thinking through it's behavioral description, I suppose my brain is not wired for this (or is too old to process and digest the required information).
But I'm not ready to give up yet...
Last edited:
I'll ask him, but my first hunch of VHDL was it's even weirder than Verilog.
I got an Altera/Intel MAX-II CPLD board and an Artsy-7 Xilinx FPGA board; handling Quartus/Vivado software is yet another very steep learning experience, but I think I got accomodated with the design flows in both (not that they are identical...).