data transfer from the the WiShield via sockets

[fdarvas]

I am trying to use the WiShield for wireless real time data acquisition, so the idea is that the Arduino gets data , one 24bit ADC value very millisecond, writes it into the socket and then a client somewhere else can read out the data in real time. For practical purposes, data could be written to a buffer, e.g. 50 samples a 3 bytes, which would then be sent off every 50 ms, or 20 times a second. Playing with the example socket app, I found out that the maximum data rate I get seems to be 200 bytes per second. Is there a way to speed this up? I can send the data through the serial interface at basically 24000 bytes a second, and it seems the throughput rate of the WiShield should be able to accommodate this transfer speed. Are there fundamental limits that limit the transfer rate to 200 bytes/s or does this require just the right implementation?

[GregEigsti]

I was just able to achieve greater than 3K per second data rate out of the Arduino/WiShield (Duemilanove). It requires a small change to the WiShield code and the sketch that I had previously sent to you. Cool thing is that with the WiShield code change I was able to run my interrupt service routine at 1 millisecond (what you desire and what had eluded me thus far, hung the Arduino). Let me know if you want me to resend my stuff to you.

I am just setting static values into my "send buffer" and I believe that you are making SPI calls to get the data. This will slow things down somewhat (?) but I cannot say for certain how much if at all.

The change to the WiShield code is in stack.c at line 68.

Code: Select all

   //original periodic timer value for polling - 500 milliseconds
   //timer_set(&periodic_timer, CLOCK_SECOND / 2);
   //new periodic timer value for polling - 100 milliseconds
   timer_set(&periodic_timer, CLOCK_SECOND / 10);


I have no idea if this change will introduce stability issues into the WiShield code but it looks pretty innocuous to me. It seemed to be stable and worked just fine the few times that I played with it.

Those in the know - will this stack.c change cause instability? Same question for further reducing the timer value.

Greg

[fdarvas]

It would be great if you could resend the code!!!! I would love to see this work wireless at 1 kHz update rate.
I had some problems with the last version (mostly that I could not open a socket anymore), and my modification of the socket app will only yield
the above mentioned 200 bytes/s. I am making SPI calls to get the data, but with the serial interface, polling 24 bit from the ADC and sending them to the serial port is no problem.

[GregEigsti]

Will send to you!

[GregEigsti]

While playing around with this stuff before sending it off to you I noticed that I was getting most of the data (over the "wire") that I expected but not all of it. The quote below is in the email that I sent you but I wanted to post it here to see if anyone else would comment...

While I have achieved the throughput that you are looking for (and believe that I could get more out of it) and can run at an interrupt time of 1ms the news is not all good. It seems that a WiShield send of a packet can take greater than 1ms (for larger packets) and the ZeroG driver disables interrupts during sends (as far as I can tell). This means that some of the 1ms interrupts to gather sensor data will not happen as occasionally interrupts will be disabled during wireless sends. I'll think about this more but I think the 1khz sampling rate is just too much for the platform.

It may be a matter of tuning but I'm wondering if a 1ms sampling time and wireless network sends are just too much for this platform - unless you want to rewrite the whole shebang in hand tuned asm

I'd love for some with more experience to chime in! fdarvas lets keep this alive, there are more options, potentially with more bulk, but we ought to be able to find something that works. Maybe a Parallax Propeller for data acquisition that sends buffer loads of data to the Arduino/WiShield for lazy transmits? Maybe you could be the first to interface a WiShield and a Propeller? I wonder what the limitations of the ethernet shield are? Don't get me wrong, I'm not asserting that this is a WiShield limitation - sampling and sending in <= 1ms on a low power processor like this is pushing it and I am impressed at the WiShield perf data that I saw tonight (most sends took 1ms or less).

Greg

[fdarvas]

If I only could get this code to work on my WiShield!! I decided to drop the samplingrate to 250 Hz, so I keep a running average of length 4 for my ADC. Now I only need to send 4 bytes every 4 ms.
What happens is that I get a few bytes (somewhere 3 and 100) and then the network connection shuts down. I have to turn off and reboot the Arduino every time after this, which makes debugging this quite tricky. I suspect there some issues on the layer below? I frequently have these crashes where basically after transmitting a few bytes, the connection just closes and can never be reopened until I reboot the Arduino.

[GregEigsti]

I received the same Arduino/WiShield hang when playing with this code; typically when I was pushing things past the limits... This code works for me but I am not hitting a SPI device every 250 ms. My guess is that the time needed to communicate with your SPI device is throwing in some additional "timing pressure". I'd try a slower sampling rate, get that working, then start tuning for speed.

Greg

[fdarvas]

When I slow things down it becomes more stable. What I plan to do is just send a buffer of 10 long ints (i.e. 40 bytes or 10 samples) every 40 ms. I don't think that the SPI polling of the ADC is taking so much time, but I might be wrong there:

Code: Select all

void read_ad_data()
{
  byte input[4];
  byte instr=192;
  write_ads1210(instr,input,0);
  pinMode(SDIO,INPUT);
  int sclk,D0;
  adc_val= 0;
  for(sclk=(NBIT-1); sclk>=0; sclk--)
  {
    digitalWrite(SCLK,HIGH);
    D0=digitalRead(SDIO);
    if(D0==HIGH)
      adc_val+=pow2[sclk];
    // Serial.print(D0,DEC);
    digitalWrite(SCLK,LOW);
    //Serial.println();
  }
  Serial.write((unsigned byte*)&adc_val,4);
}


This is the code that reads the ADC and writes it to the serial port. This worked just fine without the wishield, but obviously , the whole wireless business takes CPU time too...

[GregEigsti]

I think the whole thing is going to be finding a balance between ISR interrupt time, WiShield servicing time, length of buffer to send (longer buffers requires more WiShield servicing time), etc. Originally the max I was able to get was interrupting every 2 ms and writing two bytes per interrupt to the buffer with the default 500ms poll timer value (in stack.c) - this yielded about 1 byte per ms. Given that I was not also servicing any SPI devices, Serial.prints, etc. I reasoned that if the 500ms poll timer was decreased my buffer would be smaller (sent more often) so the WiShield servicing would take less time allowing me to crank up my own interrupt time, etc. This worked out and even seemed to make everything more stable - with the "default" settings I got the same type of Arduino "hangs" if I tried to set my interrupt to 1ms.

Given all of that goop, I think you'll just have to tune things to work as well as you can. The uIP stack seems to work but since it is written with a RAM/code constrained environment in mind there are some tradeoffs... Get it working, get it stable, crank it up till it breaks and then back it off a bit

Quick question. I noticed in your code that you removed the timer stuff that I use and (presumably) are getting your interrupts from your ADs; is this correct? How do you set their interrupt rate?

Greg

[fdarvas]

The ADC (its just a single one) sets pulls down pin 2 when it has data ready. This happens every millisecond.