Higher Precision scope (Mac based)

Woudl you happen to have complete code of gagebear (see previous posts on this thread) ?

As far as I can tell it's all here: http://gabuku.com/scope/

pix.

I don't think gagebear's Mac App is on that server but I could be wrong !

I'm pretty sure that http://gabuku.com/scope/ArduinoScope-source.zip is the source that produces http://gabuku.com/scope/Macduinoscope.app.zip .

I haven't compiled it to check though, as I don't use a Mac, but I used it as a guide to write the serial-handling parts of my app.

For completeness, http://gabuku.com/scope/arduinoScope.pde is the Arduino sketch sourcecode.

pix.

ok, I use a Mac & thought you’re using a Mac… Sorry

Is the code on that site incomplete? It looks pretty complete to me, but I'm no compiler ;)

pix

Pix: can I add support for my scope to your viewer ? I'm trying to drop my java version, so it would be nice to have a java viewer for it.

Some notes: You cannot get accurate ADC values beyond the specified ADC bandwitdh - which is very low (see datasheet). Regarding the FTDI drivers in Linux, I can hack one to use a different method so to extract data faster from arduino, but we're still limited to its small internal TX buffer. I cannot however do the same for the mac FTDI driver.

Álvaro

Pix: can I add support for my scope to your viewer ? I'm trying to drop my java version, so it would be nice to have a java viewer for it.

OpenFrameworks isn't Java, it's a cross platform C++ library. But I'll have a look at your firmware, if using it will save me hacking muli-channel into gabebear's I might start using it myself. At the moment my app definitely isn't as featureful as yours seems to be.

Some notes: You cannot get accurate ADC values beyond the specified ADC bandwitdh - which is very low (see datasheet).

Yes, I take it that the real "DANGER!!!" in using the low prescale settings in gabebear's app is that they are running faster than the bandwidth of the ADC.

Regarding the FTDI drivers in Linux, I can hack one to use a different method so to extract data faster from arduino, but we're still limited to its small internal TX buffer. I cannot however do the same for the mac FTDI driver.

I looked into this a little bit (there is libftdi for linux and OSX) but as it needed root access to the device, a method of blacklisting the usb-serial module, and extra libraries to be installed, I decided against it and used the setserial/stty wrapper instead. If there isn;'t much sense in trying to read the lower prescale rates, then I'm already managing to read the data fast enough with the built in serial driver.

pix.

I've finally figure out how to fully compile the Mac application from http://gabuku.com/scope/.

The arduino pde compiles & load OK on my mega board.

Using Xcode on my iMac running under Tiger runs OK now but some manipulation is need to store Macduinoscope special file under Xcode hierarchy folders.

Bad news: it launches but then it abort saying

[Session started at 2010-04-23 18:24:24 +0200.]

Macduinoscope has exited due to signal 10 (SIGBUS).

Maybe it is because it is because I use Mega board & pde is made for duamilanove :(

OpenFrameworks isn't Java, it's a cross platform C++ library.

.

Yes, and my only cross-platform version for scope is in java, and I'm trying to drop it. I'd love it to be C++ (like the GTK+ one and pde itself).

That would allow me to use the serpro library as-is (it's also C++).

Álvaro

Hi,

first, I was very impressed by this scope - I don’t have a Mac, but what I saw in the flash, it looks fantastic!

I have a problem. I wanted to create a similar front-end to yours, but on my Windows machine.

When I’m running this Arduino code on my Arduino Pro, I don’t get more that 200 - 250 kbps between arduino (thru the FTDI chip) into my Java Application.

Maybe you have some more experiences, what’s wrong with this code? (It’s a subset of your lines):

void setup() {

Serial.begin(1000000);
UCSR0A |= 2;

// send a message to let the computer know you are alive
Serial.print(“Hello World”);

while(true) {

//Serial.write((high2 << 5) | (low2 >> 3) | 0x80);
UDR0 = 0xff;
}
}

Is there anything special needed to set up on the port’s properties or anything?

Thanks,
Adam

wait, how are you getting 2mbps serial? It seems to me the max arduino can handle is 1mbps (16000000/(16*1000000))-1=0. What is this UCSR0A register? Thanks!

I've a iMac G5 running with Tiger OS and implemented with success Alvaro open source: maximum I can get 115K with arduino Mega via Mac based java GUI. It is my undesrtanding Arduino does not have real USB but a RS232 with USB emulation via FTDI chip so bandwith bottleneck due to RS232 modem.

The bottleneck should be in the UART itself, it takes 16 clock cycles to send a bit through the UART, so the theoretical maximum is 1000000. I suppose you could get a little higher than that because the serial is re-synced every byte, but to get any higher I think you would have to do some clever bit-banging of the serial. Of course, this guy could be using some trick I've never heard of....

Setting the U2X0 bit high in the UCSR0A registers half's the divider so it goes from 16 to 8, so you can get 2Mbps

But the arduino serial library handles that already by default, so you could do Serial.begin(2000000) from the start. (I have never tested it) The atmel datasheet even states 0,0% error rate on 2Mbps @ 16MHz so that's nice as well.

Oh, very useful to know. I wonder if this works on the attiny2313 as well...

I was not to reply to this, but here it goes.

Most serial errors occur during reception, not transmission. RS232 is asynchronous, meaning the clock is not sent along data. Although you can have both clocks with same frequency at high levels of accuracy, their phase difference is not known. This might lead to metastability problems (errors). To overcome that, most UART do oversampling on the receiver side (tipically 16). This means that for each bit being extracted, you sample 16 times. If your clock is 16MHz, your bit rate hardly goes over 1Mbit, if you want a clear transmission.

Let me try to explain how the UART receiver works.

As you know, RS232 transmission uses 1 start bit, 7-8 data bits and 0-1 stop bits. And might use parity. Let's concentrate on 8N1 (8 data bits, no parity, 1 stop bit).

So the receiver is idle, sampling 16x times faster than its baud rate, and reads a logical '0' on the wire. It keeps on going until he reads a '1'. Here it "synchronizes" its clock. Let's assume transmission is like this: 1 01010101 1 (startbit and stopbit included).

If '1' came at sampling time N, the start bit, then the first bit of data will be sampled exactly in between its start and its end - after 16 + (16/2) cycles - 1.5 bit time (includes the start bit). This ensures best setup time and hold time (setup time is the amount of time required for a signal to be stable to be sampled, hold time the amount of time required after sampling). Then others are sampled at each 16 cycles.

if your baudrate does not allow for proper center alignment, then you won't meet either setup time or hold time. If you are sampling zeroes and ones you can try resynchronizing the clock phase, but that is not used usually.

At higher baud rates, capacitance on the transmission lines shows up, greatly affecting sample+hold time. So you need a lot of precision when sampling the data bits.

Hope I shed some light on the subject. Feel free to ask for clarifications.

Álvaro

At some point, it is best to think in terms of Information Theory (Claude Shannon) where you look for bit rate (bits/s), bit error rate (10e-5), bandwith, energy (Eb/N0)... If you send at 1Mbits/s but get many errors (i.e. 10-2), it is no use. What Alvaro is doing: CRC16bits plus smart acknowledge, resend if error detected by using a channel (i.e. 115Kbits/s) but will in fact provide much less bits/s (i.e. 64kbits) being almost error free (10e-5) so his protocol takes care of corrupted 115Kbits/s being layer 1 of ISO model. In conclusion, best compare apples with apples, oranges with oranges so what bits/s you get with a fixed bit error rate where you need to normalize with overhead bits (i.e. CRC, resending same frame).

I am bumping this, because it is an existence proof that relatively high sample rates (and serial data rates) are possible. It seems to be a common misconception here that higher ADC rates aren't possible, same with high serial data rates.

360kHz sample rate is possible (if you up the ADC clock to 8MHz), as well as 2Mbit/s sample rate.

Of course you can use those rates.

But I would not trust ADC at that speed.

2Mbit for serial is possible, but I am not sure your AVR can handle it if using interrupts. If FTDI chip rx fifo was a bit larger, then I guess you could use it.

selfonlypath did a lot of testing at higher baud rates, he found the error rate too high. I’m using 3Mbit on ZPUino with not many errors (with a FTDI chip also), but I have an hardware 2kbyte fifo. Helps a lot.