I think you may be surprised. I've already heard from three programmers from the few posts I've made in just three groups. Unless you want me to send then directly to you, I am referring them to this thread.
I thought your current project was for an 8051? I guess that was old projects or maybe old programmers... lol. Your other post seemed to be talking about bitbanging the I2S port to the CODEC. How does that work into the 100 MHz need? Bitbanging a serial port of any kind can be CPU cycle intensive.
One of them contacted me already. They are sort of local but not really local-local, like in the same village, down the road from here. We will have lots of situations such as "Hey, I got stuck with the test rig, can you come over real quick?" or "The relief valve over yonder blew a gasket, can you replace it?".
[...]
No, no, that was just an example for why certain architectures never die. One on my 8051 projects will soon have it's 20th and no slow-down in production in sight. On the contrary.
Yes, it is a major concern. We might need to hang an FPGA in there at least for TX, as a buffer, because essentially we are writing sine waves. Doesn't work on RX though, that's time-varying stuff. I hope I2S works for us, somehow. Got to find out.
So why aren't you working in the same lab? Then it can be like, "Watson, come here. I want you".
BTW, if you heard from Charley Shattuck, he is a prominent Forth programmer. He is working with a startup that developed a Forth like CPU with 144 processors with a peak rate of 700 MIPS each. This chip includes 5 ADC and 5 DAC on chip with variable resolution (trade off between speed and resolution, about 15 bits at 48 ksps). You might talk to him about the GA144, it might suit your needs. It's main limitation is each processor has little memory and the I/O is limited. But I don't think you will run out of MIPS. lol
???
What are the specs you need from the ADC? Do you have numbers and such? I think you mentioned a low drift with temperature. The GA144 would need to be compensated for temperature, but has lots of processing to do that. :)
Because as mentioned before if both are consultants it creates confidentiality issues. I have only one room (office plus lab) and another one mostly used for library and parts storage but not acoustically shielded. I often have to hop on GoTo or some other service to discuss another client's issue and then I must be alone. Sometimes for 1-2h. In contrast to contractors who work one longer assignment at a time I always have half a dozen or more active clients.
Yes, had an email exchange with Charley.
144 processors with 700MIPS each would probably require us to also build a nuclear power station :-) ... just kidding, I know it's green.
Well, to send out sine waves. No need to necessarily bother a processor with that. Or I use a DDS but that can cost in clock synchronicity.
Five needed in total, 18bits or more, 48ksps, differential inputs, BW from DC to 15kHz, without phase jitter issues. DC-Offset can be handled via mux and SW-clamping as long as it won't jitter or drift around much.
That sounds more like a need for a local technician than a programmer!
Virtually none of FORTH, Inc.'s customers for whom we do application work are local to us; our most recent major projects were in Vancouver BC and Texas. The model we use is to go on site for one or more visits (typically a couple of weeks) to get the system part (drivers, application design, main body of code) working and the customer's local programmer(s) trained. If there is custom hardware and it's portable, we ask for one unit to take home. Thereafter, we consult remotely on both hardware and software issues. This takes advantage of the fact that the customer has far more detailed understanding of the application domain than we do, but we have the experience to help get the system design off on the right track and provide continuing support (including more visits if necessary).
Cheers, Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Each processor is very low power when running flat out, just 5 mW. But they almost never run flat out. Because they are asynchronous they spend most of their time stopped when they draw 0.0875 uW, yes, that's less than a tenth of a uW for each processor or just 12 uW for the whole chip. The processors respond to stimuli in just nanoseconds, not 100's or even 10' but single digit nanoseconds.
Trust me, power will not be a problem with this part. It is a very different beast to program however.
Every problem in your design is asking for an FPGA.
"phase jitter issues" and "won't jitter or drift around much" aren't specs. 18 bits of what exactly? I have seen lots of devices with 24 bits but only 96 dB SNR. Do you need 108 dB SNR? You won't get that from the GA144 ADCs at 48 kHz.
Joerg is describing what might happen that means he needs to have the consultant minutes away. The consultant won't be fixing the gasket, Joerg will. I didn't realize Joerg has a small lab without room for two people to work separately.
I wonder how that company is doing. I read about their products years ago but never seen any in schematics and I get to see a lot of new stuff because some of my daily bread is EMC remedy.
Possible, but not sure yet. Maybe there is a bigger processor out there with real I2S/TDM and enough support by the manufacturer.
What I mean is that ADCs on processors generally cannot hold jitter low enough to truly deliver a 96dB SNR. I found that even 12 bits on-chip is already a serious challenge.
18 bits of what exactly? I have seen lots of devices with 24
This is a one-of-a-kind tester that I designed and built myself, with the help of an aerospace engineer. Only one such tester exists in the world and I am currently the only person who can fix it if something breaks. The tester is only useful for this particular project. Both the programmer and I must use it a lot towards the later phases of the projects.
That is how I also normally work, most times I actually never see my clients face to face except in online meetings. But this project is different. The software cannot be optimized without working right at the test apparatus. Since it involves a compressor, pressurized buffer tanks, valves and such it is also something where I must be present for safety reasons. I would never let anyone using it by themselves.
I think they are doing ok, but mainly because they have nearly zero overhead. They don't pay any salaries so no need for layoffs.
Yeah, maybe. You can go with one of the Cortex A processors like they use in the Beagle board or Raspberry Pi. Without the Linux OS they should so a decent job. They have floating point for your FFTs as well. That will help prevent too much rounding noise in the FFTs.
So a 16 bit part with DC coupling would be good enough? The market is
*littered* with those. I've seen a bazillion 18 bit SAR parts out there. Even LT has them, your favorite company. Why not use one of those? They often have fantastic SNR and THD specs.
How about an 8 channel, 16 bit ADC in one package?
formatting link
Well, maybe not. The SINAD is not so good. What is the frequency of the signal you are looking at? The ADC specs also depend on your input frequency.
The point is that if you can drop the I2S interface you have a lot more potential MCUs to choose from.
All kidding aside, your application may be one that is well suited to the GA144. With your data rates the GA144 can certainly keep up processing wise. The CODEC I/O would be no problem at all. The I2S interface can be bit banged by 700 MHz processors.
The only issues would be designing the algorithms to perform the signal processing. There is no math library that I know of. So you would need to design your own.
I think the chip would be running at a small fraction of a watt. With every node running flat out the power consumption is under a watt.
Not that it is a serious contender, but ADI makes an old ARM7 chip with
16 bit ADCs on board, not sure how many, I don't think it was five, it may have been four. It was only 33 MHz and doesn't have any of the DSP like instructions. But they designed it with the analog in mind. I seem to recall they marketed it with their ADC families rather than with their processors.
The GA144 ADCs are just not quite there. Like I said, they get 15 bits at 48 kHz sample rate. I don't recall how slow the sampling needs to be to get 16 bits (96 dB nominally). Likely it is about 12 kHz.
The important point here is that on the GA144 you can get better resolution by slowing down, and higher speed by scarificing resolution. Or so they say.
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Wow. So they all work for free? How do they make a living?
Except the Sitaras in QFP have been obsoleted. But I'll find something.
No, because ENOB counts and there you need around 18 bits.
DC to 20kHz but that requirement can be dropped to 10kHz. Also, if I really, really had to, I could replace one of the two DACs with a DDS chip because that just generates a sine wave. But it complicates the SW because such chips need their own SPI sermons in Swahili.
Sure, if the CPU can manage to keep seven balls in the air and serve all those SPI device at 48ksps.
That is something we really want to avoid. Funding for this project is not unlimited but most of all there isn't an infinite amount of time. So we'd like to rely of pre-canned packages for complex FFT, phase calculations, IIR/FIR filtering, Goertzel and so on.
That would of course be nice but 5W would be fine as well. Meaning we'll need a QFP with a heat sink pad underneath.
That's too slow and also ADCs on board of CPUs usually have subpar noise behavior, IME. I don't know that processor but don't want to take the chance because you won't discover until at the very end of the project.
In order to reach 96dB the ENOB has to be 16 bits at max speed, meaning in reality most ADC would have to provide 18 bits.
Yes, it is an integrator in the true sense. It has a VFO which is controlled by the analog input and increments a counter. The period is set by reading the counter at defined intervals and taking the difference. The VFO curve is not exactly linear, so it needs to be corrected in software as well.
The interesting part is that you can add adjacent readings and get the same result as if you were reading the counter at a slower rate. So the added resolution can be done in software without changing the actual read rate. If that is set by a stable clock like a crystal it doesn't need to be slowed down to have variable rate and resolution.
I think I was confusing two things. When you are looking at improving SNR, adding samples gains SNR by the square root of the number of samples. Gains in resolution are logarithmic with the number of samples, so halving the sample rate gets you 1 extra bit meaning the GA144 ADCs will get 16 bit resolution around 24 kHz sample rate.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.