@pic18f2550 said:
Ok, now I understand a few things better.
What would happen if I were to add another block?
sub Lsmp,Ldiff1
add Ldiff1,Lsmp
sub Lsmp,Ldiff2 'Sinc3
add Ldiff2,Lsmp
sub Lsmp,Ldiff3 'Sinc?
add Ldiff3,Lsmp
The number of derivative stages has to match the number of integral stages to be regular PCM samples. If you had a need for integral derivative of the regular PCM value, maybe it would be useful.
Ok, I'll have to take a look at that first.
If need be, 16 bits will do.
Now I have enough food for a while.
The next thing to do is to store the amount of data.
The internal memory is too small, so only SD/CF cards remain.
500k * 3 byte * 8 bit = 12 Mbit/s
500k * 3 byte = 1.5 Mbyte/s
It would be full after 21 seconds with one channel.
I need 4 channels.
I will need an SD card for each channel.
I will write to the card in raw format (PASM).
I will then read it back into a file with dd in Linux.
It would be full after 21 seconds with one channel.
I need 4 channels.
I will need an SD card for each channel.
I will write to the card in raw format (PASM).
I will then read it back into a file with dd in Linux.
If you have an RPi, you can connect it to a P2 via i2s and/or UART(s) and let the Pi do the file processing stuff. Up to 4 Mbps is available via UART on RPi/Linux, without Linux the cable makes the limit. (RPi theoretical limit is 250 Mbps if PLLD is used as a clock source for UART)
I would have to buy two Pis.
That's no use in the end because I have to have the data on the PC anyway.
Unfortunately there is no real USB connection to the PC, then you could transfer 250Mb/s in bulk mode.
Microchip already has the appropriate USB 2.0 driver for Windows/Linux.
That's for using a HDD. You can't talk to a PC with that, or at least not without writing a driver for that side too. Me thinks better to stick with the SD card idea.
SD card via SPI looks bad at 2.25 MByte data per second and channel. That would be a CLK of 18Mhz per channel, I think that would be a bit too much for the SD card.
The HDD is not for the PC, it is only to buffer the fast data. The data export goes via an SD card.
But I'll make another post for that when the time comes.
SDIO SPI mode at High-Speed (50 MHz) is fast enough for Class 6 (6 MB/s writes) rating. That's enough for what you need. Just a case of nutting out how to do sustained writes.
The fastest access I could get on the P1 was with @lonesock's driver for FSRW.
Hitting 1,200 MB/s with FAT access. Using block-reads or writes and buffering in the COG ram for read ahead and write behind. That is what @lonesock's driver does, not my work.
The main speed gain of FSWR compared to Fat32Engine from Kyle is that the Driver in FSRW runs really parallel the main COG does not need to wait for a write to SD after giving the HUB address, it gets a OK after the HUB buffer is copied to COG ram (very fast idea or @kuroneko) and the main COG can fetch new data while the other COG is streaming out from COG ram to SD.
For reading @lonesock's driver is even more genial. Read ahead!
So if you ask for sector say 123 it will read 123 and deliver it to HUB. And then it simply reads 124 just in case you ask for it next. Then it is already there and can simply be delivered without delay and the next sector gets fetched.
On the P2 we could have 4 Buffers of 512 Bytes in the LUT so we could even read/write 4 sectors in block mode speeding up things again.
Except my Computer everything is in boxes (moving into new man-cave), not even one P2-Eval at hand, but I am pretty sure that a SD-BLOCK driver like @lonesock's for FSRW could really shine.
I made a Version of Kye's driver using Lonesock's PASM for my RAISD system, need to dig for it.
Sadly I just have time to loosly follow this, life is taking a lot of time, currently.
But a buffered access to SD will speed things up a lot.
@Ariba said:
I always wonder a bit what people expect from ADCs. I find the internal ones quite acceptable for audio.
I have written a test program here that allows to sample short audio snippets into the Hubram, and listen to them again and also save them as WAV file via the fileserver of flexProp onto the PC. Recording and playback is done via the same stereo jack (my board has only one audio port).
To use the memory well I use only 16bit mono samples, and only with 48 kHz. The ADCs could also do 18bit at 384 kHz, or more.
In the ZIP file there are 2 WAV files, one with music, and one with silence. In the latter one you can judge the noise level well. Additionally I analyzed the frequency response with Audacity, the result is visible in the diagram. However, I do not know how meaningful this kind of measurement and analysis is, compared to the diagrams from the data sheets of the above ADCs.
O.K. I took YOUR short music clip and ran it through "Rubidium", which is my own home grown spectrum analyzer project, and what I am seeing is that the noise floor is at or below the baseline level pretty much over the entire range of human hearing, i.e. looking at a "frame" at 00:00:28 based on SMPTE non-drop rate, 48000 H on a "real time" log-log plot I am seeing spectral energy lows of -94db or better relative to full scale, i.e., while looking at the musical passage - for example around the first B-flat on the range of piano notes - approximately 30Hz. So definitely CD quality if the low frequency noise can be filtered out. Have you tried running an audio signal into two pins in differential mode? Maybe the A-D internal reference voltage is bouncing up and down with fluctuations in CPU activity. which might simply mean that thee power supply coupling capacitors are too small, so maybe there is a fix for that externally? So it might be too soon to say if there is a problem with the silicon, i.e., such as in the form of a high resistance path on the chip - but I would think that if there were such a path in the reference, bias, or whatever, that there would be trash across the whole spectrum, since there probably isn't a whole lot of decoupling capacitance on the silicon, as that is kind of hard to do. Of course one traditional approach is to use a so called "chopper" modulator which is a circuit that acts like a double pole double throw phase reversing switch on an input or pair of inputs when run in differential mode. Such circuits go back to the era of vacuum tubes, and were used "even back in the day" to achieve near zero DC offset current and low frequency noise for such thing as EKG, EEG, seismographs, etc. When I looked at the data sheet for one Texas Instruments A-D, I think that THEIR spectrum analyzer plot shows a "birdie" in their spectrum somewhere around -84db at around 40kHz.
@Ariba said:
I always wonder a bit what people expect from ADCs. I find the internal ones quite acceptable for audio.
I have written a test program here that allows to sample short audio snippets into the Hubram, and listen to them again and also save them as WAV file via the fileserver of flexProp onto the PC. Recording and playback is done via the same stereo jack (my board has only one audio port).
To use the memory well I use only 16bit mono samples, and only with 48 kHz. The ADCs could also do 18bit at 384 kHz, or more.
In the ZIP file there are 2 WAV files, one with music, and one with silence. In the latter one you can judge the noise level well. Additionally I analyzed the frequency response with Audacity, the result is visible in the diagram. However, I do not know how meaningful this kind of measurement and analysis is, compared to the diagrams from the data sheets of the above ADCs.
O.K. I took YOUR short music clip and ran it through "Rubidium", which is my own home grown spectrum analyzer project, and what I am seeing is that the noise floor is at or below the baseline level pretty much over the entire range of human hearing, i.e. looking at a "frame" at 00:00:28 based on SMPTE non-drop rate, 48000 H on a "real time" log-log plot I am seeing spectral energy lows of -94db or better relative to full scale, i.e., while looking at the musical passage - for example around the first B-flat on the range of piano notes - approximately 30Hz. So definitely CD quality if the low frequency noise can be filtered out. Have you tried running an audio signal into two pins in differential mode? Maybe the A-D internal reference voltage is bouncing up and down with fluctuations in CPU activity. which might simply mean that thee power supply coupling capacitors are too small, so maybe there is a fix for that externally? So it might be too soon to say if there is a problem with the silicon, i.e., such as in the form of a high resistance path on the chip - but I would think that if there were such a path in the reference, bias, or whatever, that there would be trash across the whole spectrum, since there probably isn't a whole lot of decoupling capacitance on the silicon, as that is kind of hard to do. Of course one traditional approach is to use a so called "chopper" modulator which is a circuit that acts like a double pole double throw phase reversing switch on an input or pair of inputs when run in differential mode. Such circuits go back to the era of vacuum tubes, and were used "even back in the day" to achieve near zero DC offset current and low frequency noise for such thing as EKG, EEG, seismographs, etc. When I looked at the data sheet for one Texas Instruments A-D, I think that THEIR spectrum analyzer plot shows a "birdie" in their spectrum somewhere around -84db at around 40kHz.
Following up - if I "shift everything up" five octaves (I think) - since I use "piano frequencies" at one semi-tone per minor division and one octave per major division, then based on the same WAV file, my software is in agreement with what you are seeing with Audacity, that is to say below 20 Hz - with a noise floor rising to something like -40 db relative to full scale -not sure of the exact frequency in this mode however, probably between 1Hz and 32 Hz - 10 db per major division relative to "full" scale.
@msrobots said:
Those numbers are for P1, I guess P2 will do better.
Ah, that makes sense, it was likely limited by the bit-bashing and associated looping. Yes, I'd hope the Prop2 can push that way up with hardware assistance both with the bit to bit timing as well as concurrency eliminating overheads.
2.25 MByte/s is from GOG via hram to GOG to the storage medium without FAT system.
And the whole thing for 4 channels the data is stored one after the other like in a WAV file.
I don't know what all the discussions are about.
Two measurement experiments are sufficient for the assessment of ADC.
1. DC level in different ranges. Here you can determine the noise floor.
square wave signal with 25% to 75% of the maximum input level. Here you can determine the transient and overshoot behaviour of the DAC. In the same way, you can also determine the mirror frequency of the DAC in order to obtain the maximum possible audio frequency after applying the filter.
In hinterkoppf there is another variant with 36 bits.
The trick is hidden in the analogue computers.
Okay, got it, no filesystem, no C. Dunno how far I'll get. Need to dig up existing code ...
Just reading the SD-v6 PDF, It reckons Class 6 is achievable at Default Speed. That's cool. One less initial hurdle to climb. Err, of course, that'll be 4-bit mode. Lol, doesn't bode well for SPI mode ...
This section is a blank in the Simplified Specification
Figure 3-1 : SD Memory Card System Bus Topology
Figure 3-2 : SD Memory Card System (SPI Mode) Bus Topology
Figure 3-3 : UHS-II Bus Topologies
Lol, wow, the PDF has blanked pages for some diagrams ... but I found they aren't truly blank. Just some sort of white cover over the content. EDIT: Hmm, okay, maybe only the diagram headers are still there.
Here's a big difference between old and new cards in SPI mode:
In the case of a Standard Capacity Memory Card, a data block can be as big as one card write block and as small as a single byte. Partial block read/write operations are enabled by card options specified in the CSD register.
In case of SDHC and SDXC Cards, block length is fixed to 512 bytes. The block length set by CMD16 is only used for CMD42 and not used for memory data transfer. So, partial block read/write operations are also disabled. Furthermore, Write Protected commands (CMD28, CMD29 and CMD30) are not supported.
Oh, in SD DDR 4-bit mode, 1.8 Volt signalling is still 3.3 Volt supply. bitDAC can certainly do that. Not so sure the comparator input will go that fast though. Could be fun to try in the future.
The Amiga 500 has a simple interface that can be easily implemented on the P1/P2.
U2 -> 1x 74LS244 + 1x 74LVX244
U3 -> 1x 74LS244 + 1x 74LVX244
U4 -> 1x 74LS244
The rest is not needed because the signals come directly from P1/P2.
Instead of the INTRQ we simply query the register in the HDD.
Comments
Ok, now I understand a few things better.
What would happen if I were to add another block?
sub Lsmp,Ldiff1 add Ldiff1,Lsmp sub Lsmp,Ldiff2 'Sinc3 add Ldiff2,Lsmp sub Lsmp,Ldiff3 'Sinc? add Ldiff3,LsmpThe hardware accumulators are 27 bits with a
zerox Lsmp,#26 'match to 27-bit hardware accumulators shr Lsmp,#3 '24-bit samples, 27 - 16 = 11should a 24 bit also be possible?
The number of derivative stages has to match the number of integral stages to be regular PCM samples. If you had a need for integral derivative of the regular PCM value, maybe it would be useful.
Yes, but very noisy.
Do you mean P_ADC_1X and P_ADC_3X?
For the analogue voltage gain setting, yes.
Ok, I'll have to take a look at that first.
If need be, 16 bits will do.
Now I have enough food for a while.
The next thing to do is to store the amount of data.
The internal memory is too small, so only SD/CF cards remain.
500k * 3 byte * 8 bit = 12 Mbit/s
500k * 3 byte = 1.5 Mbyte/s
Let's see what I use here.
Thanks
Not quite in the shop yet but there is the P2-EC-32MB Board (32 MB of DRAM) designed for just that sort of action - https://forums.parallax.com/discussion/comment/1529355/#Comment_1529355
Ha ha evanh.
It would be full after 21 seconds with one channel.
I need 4 channels.
I will need an SD card for each channel.
I will write to the card in raw format (PASM).
I will then read it back into a file with dd in Linux.
If you have an RPi, you can connect it to a P2 via i2s and/or UART(s) and let the Pi do the file processing stuff. Up to 4 Mbps is available via UART on RPi/Linux, without Linux the cable makes the limit. (RPi theoretical limit is 250 Mbps if PLLD is used as a clock source for UART)
I would have to buy two Pis.
That's no use in the end because I have to have the data on the PC anyway.
Unfortunately there is no real USB connection to the PC, then you could transfer 250Mb/s in bulk mode.
Microchip already has the appropriate USB 2.0 driver for Windows/Linux.
Ok.
An IDE hard disk could still be a possibility. Is there anything available yet?
Sample for 8 bit.
http://retro.hansotten.nl/6502-sbc/lee-davison-web-site/ide-bus-interface-circuit/
That's for using a HDD. You can't talk to a PC with that, or at least not without writing a driver for that side too. Me thinks better to stick with the SD card idea.
SD card via SPI looks bad at 2.25 MByte data per second and channel. That would be a CLK of 18Mhz per channel, I think that would be a bit too much for the SD card.
The HDD is not for the PC, it is only to buffer the fast data. The data export goes via an SD card.
But I'll make another post for that when the time comes.
SDIO SPI mode at High-Speed (50 MHz) is fast enough for Class 6 (6 MB/s writes) rating. That's enough for what you need. Just a case of nutting out how to do sustained writes.
The fastest access I could get on the P1 was with @lonesock's driver for FSRW.
Hitting 1,200 MB/s with FAT access. Using block-reads or writes and buffering in the COG ram for read ahead and write behind. That is what @lonesock's driver does, not my work.
The main speed gain of FSWR compared to Fat32Engine from Kyle is that the Driver in FSRW runs really parallel the main COG does not need to wait for a write to SD after giving the HUB address, it gets a OK after the HUB buffer is copied to COG ram (very fast idea or @kuroneko) and the main COG can fetch new data while the other COG is streaming out from COG ram to SD.
For reading @lonesock's driver is even more genial. Read ahead!
So if you ask for sector say 123 it will read 123 and deliver it to HUB. And then it simply reads 124 just in case you ask for it next. Then it is already there and can simply be delivered without delay and the next sector gets fetched.
On the P2 we could have 4 Buffers of 512 Bytes in the LUT so we could even read/write 4 sectors in block mode speeding up things again.
Except my Computer everything is in boxes (moving into new man-cave), not even one P2-Eval at hand, but I am pretty sure that a SD-BLOCK driver like @lonesock's for FSRW could really shine.
I made a Version of Kye's driver using Lonesock's PASM for my RAISD system, need to dig for it.
Sadly I just have time to loosly follow this, life is taking a lot of time, currently.
But a buffered access to SD will speed things up a lot.
Mike
I'll assume that is 1200 kBytes per second. Might need some investigating as to why it wasn't going even faster.
try for your self, look at the code I think this is the max you can do with the p1
Fat_Engine peters out at ~780KB/s and FSRW does 1.200KB/s (using FAT32)
Direct SD access (without FAT) might be slightly faster without the Spin overhead of both drivers.
Those numbers are for P1, I guess P2 will do better.
Mike
O.K. I took YOUR short music clip and ran it through "Rubidium", which is my own home grown spectrum analyzer project, and what I am seeing is that the noise floor is at or below the baseline level pretty much over the entire range of human hearing, i.e. looking at a "frame" at 00:00:28 based on SMPTE non-drop rate, 48000 H on a "real time" log-log plot I am seeing spectral energy lows of -94db or better relative to full scale, i.e., while looking at the musical passage - for example around the first B-flat on the range of piano notes - approximately 30Hz. So definitely CD quality if the low frequency noise can be filtered out. Have you tried running an audio signal into two pins in differential mode? Maybe the A-D internal reference voltage is bouncing up and down with fluctuations in CPU activity. which might simply mean that thee power supply coupling capacitors are too small, so maybe there is a fix for that externally? So it might be too soon to say if there is a problem with the silicon, i.e., such as in the form of a high resistance path on the chip - but I would think that if there were such a path in the reference, bias, or whatever, that there would be trash across the whole spectrum, since there probably isn't a whole lot of decoupling capacitance on the silicon, as that is kind of hard to do. Of course one traditional approach is to use a so called "chopper" modulator which is a circuit that acts like a double pole double throw phase reversing switch on an input or pair of inputs when run in differential mode. Such circuits go back to the era of vacuum tubes, and were used "even back in the day" to achieve near zero DC offset current and low frequency noise for such thing as EKG, EEG, seismographs, etc. When I looked at the data sheet for one Texas Instruments A-D, I think that THEIR spectrum analyzer plot shows a "birdie" in their spectrum somewhere around -84db at around 40kHz.
Following up - if I "shift everything up" five octaves (I think) - since I use "piano frequencies" at one semi-tone per minor division and one octave per major division, then based on the same WAV file, my software is in agreement with what you are seeing with Audacity, that is to say below 20 Hz - with a noise floor rising to something like -40 db relative to full scale -not sure of the exact frequency in this mode however, probably between 1Hz and 32 Hz - 10 db per major division relative to "full" scale.
Ah, that makes sense, it was likely limited by the bit-bashing and associated looping. Yes, I'd hope the Prop2 can push that way up with hardware assistance both with the bit to bit timing as well as concurrency eliminating overheads.
2.25 MByte/s is from GOG via hram to GOG to the storage medium without FAT system.
And the whole thing for 4 channels the data is stored one after the other like in a WAV file.
K1Hb, K1Mb, K1Lb, spare, K2Hb, K2Mb, K2Lb, spare, K3..., K4..., K1...
I don't know what all the discussions are about.
Two measurement experiments are sufficient for the assessment of ADC.
1. DC level in different ranges. Here you can determine the noise floor.
In hinterkoppf there is another variant with 36 bits.
The trick is hidden in the analogue computers.
FlexC has SD support for C's standardised fwrite(). I'll have a nosey at that tomorrow hopefully.
c no thanks, I won't do that to myself.
Assembler or Spin are enough for me.
Okay, got it, no filesystem, no C.
Dunno how far I'll get. Need to dig up existing code ...
Just reading the SD-v6 PDF, It reckons Class 6 is achievable at Default Speed. That's cool. One less initial hurdle to climb. Err, of course, that'll be 4-bit mode. Lol, doesn't bode well for SPI mode ...
Lol, wow, the PDF has blanked pages for some diagrams ... but I found they aren't truly blank. Just some sort of white cover over the content. EDIT: Hmm, okay, maybe only the diagram headers are still there.
Here's a big difference between old and new cards in SPI mode:
Hehe, this'll be interesting:
yes FSRW and Fat_Engine take care of that and byte addressing is pretty much gone over 2GB.
So actually a new driver would not really need to take care of byte addressed cards, they are more or less gone.
Interesting would be the supported transfer speed hidden in some of them registers of the card because a P2 can outrun those cards easy.
Anyways I can't program much right now anymore, loosing my eyesight rapidly.
Mike
Oh, in SD DDR 4-bit mode, 1.8 Volt signalling is still 3.3 Volt supply. bitDAC can certainly do that. Not so sure the comparator input will go that fast though. Could be fun to try in the future.
Mike,
Do you know if all existing versions are SPI mode? I'm guessing yes.
The Amiga 500 has a simple interface that can be easily implemented on the P1/P2.
U2 -> 1x 74LS244 + 1x 74LVX244
U3 -> 1x 74LS244 + 1x 74LVX244
U4 -> 1x 74LS244
The rest is not needed because the signals come directly from P1/P2.
Instead of the INTRQ we simply query the register in the HDD.