Serial Web Services API and GET

[noelportugal]

After some thinking I got a revelation!

Now I'm just sending the WAV file number (1-50) into the serial board. Then I use the ioBridge JSON feed to retrieve the data.module.channels[3].LastSerialInput. I poll this (the broser client) every 10 seconds and now I know which WAV is playing.

My original REST service was returning a command to the serial board, now I just use the javascript widgetSetString('XXXXXXXX',MyCommand%0D%0A') method.

So basically now I'm doing a poll instead of a pub. It is my understanding that the feed will be cached every 10 seconds and I believe it will not create great stress to the servers.

I will still like to use serial GET with a long(er) URL in the future. So let me know of your findings

-Noel

[noelportugal]

Great news!!! So your fix/response came right before my last post...So I guess now i can try both models and see what works best!

Thanks for the great support!

[iobridge]

We made some notes on the Wiki page regarding the message limits:

http://www.iobridge.net/wiki/api/serial-web-services-api

If you provide pacing between 200B chunks you can send commands that are longer. But, if you jam the command into the board, the command will get cut off and not execute properly.

Tested with IO-204 C4.1 and an arduino I was able to send very long emails.

[texasclodhopper]

Geez, I can only hope to know more about what you guys are discussing! 

It's very interesting, though, and I better start cracking the books as you lead the way!

[nick]

Thanks Jason and Hans for fixing this.  I believe that this is the most important feature in the IOBridge, it opens up a world of possibilities.

I have a question about what the Wiki page says:

The serial smart board has a buffer of 200B. When the buffer is full, the RTS pin goes high. The buffer clears a moment later and you can send more data. You can send long commands thru the board if you put a second of pacing between 200B chunks of the message.

Is the pacing needed in addition to monitoring RTS? Or is it an alternative?  It sounds like there are two ways to avoid overflowing the buffer: 1. always wait at least a second between chunks; or 2. always wait for RTS before sending.  Is that correct?

The UART on my Arduino implements RTS/CTS flow control in hardware so I should just be able to hook RTS on the SSB to CTS on the Arduino.  Although I have to run it through an inverter because the CTS logic on the Arduino is inverted.

[An aside: normally RTS changes not when the buffer is full, but when it is almost full. Otherwise you can lose data in the time between when the receiver notices that the buffer is full and the sender stops sending].

Also, doesn't RTS go low not high when the buffer is full?

Nick

[iobridge]

Like you figured out, pacing is just another way. The natural emptying of the serial board is every 1s plus minus 100ms. If your microcontroller can send the data in bursts, the serial data will get thru just fine.

I sent a 5 paragraph email, about 1200 characters.

We also fixed it for going to websites that add a bunch of special chars. If you get a website, it will reply with the first 70-80 characters of the site.