It would help to know a little more about what you're trying to accomplish.

If all you want is to see the traffic going to the printer, USB sniffing on the PC side might be worth checking out as an easier approach to getting the data.

br

You're going to have to decide whether you want to use a web server / HTTP approach or an old-school telnet-style approach on the Arduino.  There are plenty of examples for the web server case (and in fact Zoomkat will be here any second to share some solid working HTTP code.)

It might be worth taking a look at the BitlashWebServer example that ships with Bitlash (http://bitlash.net).  It's a sketch that exposes Bitlash scripting as a web service from the Arduino over Ethernet.  It also has a telnet server so you can just send commands, as opposed to commands wrapped in HTTP GET requests.

For your project you could just send "d13=1" to turn on the LED on pin 13, and "d13=0" to turn it off.

Bitlash here: http://bitlash.net and you can browse the web server/telnet sketch code that ships in the distribution here: https://github.com/billroy/bitlash/blob/master/examples/BitlashWebServer/BitlashWebServer.ino

Good luck with your project,

-br

Edit: D13 is not going to work for an LED because it is used by the Ethernet shield.  Discovered this while creating a new built-in script for the BitlashWebServer.  But now you can open a browser on the server ip-address/toggle5 and it will turn pin 5 on and off.

It is hard to give advice without seeing the code for both transmit and receive.  Does the problem get worse under load?

-br

It's best to check the value before writing to save a write cycle if possible.  The AVR does not check.  And there is a limit to the number of write cycles, on the order of 500,000.

-br
http://bitlash.net

Thanks for your kind words about Commander.

That wi-fi part is interesting.  The data sheet doesn't specify an operating voltage, which is at least a little bit curious.  If you have a 3.3V mini, you need to be careful around 5V hardware.

-br

That's a good place to start.

In Bitlash, you'd approach it a little differently:

You'd do the usual initialization in a function named 'startup':

Code:

    function startup {pinmode(13,1);}

…and then you'd type (or send from a PC side program):

Code:

    d13=1      // to turn it on, and
    d13=0      // to turn it off

Once you've got it under command line control, Commander can put it on the web.

-br

One way to skin that cat would be to attach a bluetooth serial adapter to the mini, rendering it portable/wireless, and control it over bluetooth serial from the PC side with something like Bitlash Commander: https://github.com/billroy/bitlash-commander -- which also exposes a web control panel interface so you can switch your LED on and off in the browser.

Mind the 3.3V vs. 5V supply and signal issues when you buy stuff to go with the Mini, especially if you are thinking about going with a shield for the regular Arduino form factor and some ad-hoc wiring.

Good luck with your project,

-br

That is one cool tank. 

Here's a first look at the XY-control.  Still some little bugs, but it will be stable soon:


-br

For user input, read up on Serial.available() and Serial.read().

-br

One angle on this would be to use a commercial phone app service like Twilio (http://www.twilio.com/voice/api, no affiliation) to handle the details of the telephone side.  You develop a little app on their service and it POSTs some XML to a destination of your choice, perhaps an arduino with an ethernet shield.

-br

Supposing that you had arranged for the style sheet to be available on the web at http://server.com/style.css, in your generated html output, in the head section, you would include something like this:

Code:

<link rel='stylesheet' href='http://server.com/style.css'>

More here: http://stackoverflow.com/questions/1645860/css-import-from-another-server

-br

To work on the controls requires only a browser and text editor.

I'm actively developing Commander, so if you check back in a couple days it will probably have an XY control.  No guarantees...

Your bigger task is building out the robot side and getting the software to drive it hooked up and under control of the Bitlash interpreter on Arduino.  Once you can control your robot from the command line, it's ready for a Commander control panel.

The tricky part about implementing "go forward" and "go left" at the same time is not at the control panel end, it's on the Arduino where you have to work out how to walk and chew gum at the same time.  To go forward 10 and left 5, for example, you can just go forward 10 and then go left 5, but most people probably expect that a robot will go forward a little and left a little to more or less move in a straight line.  So you end up breaking larger moves into smaller ones you can interlace.  That requires a little thought.


-br

Thanks for your note…

1. So, how difficult is it to modify the Bitlash controls? Ideally I would like to have a virtual joystick, basically just a circle with a dot in it that can be dragged with the mouse for driving the rover. Like putting it in the top left would make it steer left while moving forward. Is there a GUI I can use to redesign the Bitlash GUI to be something like this? Do the controls act like a continuous input until released and "auto center" when released? If not, how hard would that be to program? I would want it to stop as soon as I released the slider/joystick or if there was an interruption in the connection.

Moving the controls you see around, changing their size/shape/contents is easy. 

But you are proposing something a little more, a new control, an XY-type joystick control.  Cool idea.  New controls are not hard, but they are integrated pretty deep.  They're implemented in javascript in public/svg-controls.js if you want to take a look.

What you're proposing isn't hard.  Let me think about it a bit.  Meanwhile, you can get a lot of what you want with sliders, for a prototype.  Give that a think and see where you can get with it.

2. Could the Bitlash webpage be hosted on the arduino itself like on an ethernet/wifi shield? If possible, I could use an RF solution of getting the video to another PC for the video encoding and not have to have a PC on the rover. Or maybe it would be better to use an XBee between the server and the rover/arduino and only have arduino, and XBee and an RF video TX on the rover.

Sorry, the smallest thing I believe Commander will run on (so far) is the Raspberry Pi, which I haven't tested yet but understand runs node.js.

But you could use any remote serial connection you like between the PC hosting Commander and Arduino; I routinely talk to remote Bitlash over Bluetooth, for example.  I understand it's possible to use XBee for similar, but haven't done it.  As long as Commander can open it as a serial port, it can send commands to it.

-br

You know, on further reflection, if the software part of that approach turns out to be too costly, it's really easy to set up a little off-the-shelf linux box with a GPS as a real ntp time source.  If you have any PC workstations or servers on your LAN already, you could host a server there without even adding a box.

-br

Oops, sorry, I see that was a red herring.  No other easy pickings in plain sight after a bit more searching, either.

Faced with this problem, I'd start looking for C reference implementations of the NTP protocol and see how much you can slim down a fibbing timeserver.

Here, for example, is a client implementation in C; maybe you can deduce what to feed it to make it happy: http://doolittle.icarus.com/ntpclient/

The protocol is well-documented, too…

-br