the sensor can also output digital serial and pulse width
I haven't used that specific sensor before, but I'd certainly be tempted to try switching to digital comms for this purpose if the sensor supports it. Use the hardware UART though, not SoftwareSerial, otherwise you'll be back in the land of painful timing interactions. -- Jon
For what it's worth, I had big problems trying to get VUSB to cooperate with analog readings. The timing is just too critical. For example, I did this little hack using a DS touchscreen to control Frozen Bubble:
My first attempt used one Arduino to read the touchscreen (which requires multiple analog reads) and then send the appropriate events to the host using VUSB. That totally failed, so for that video I used two Arduinos: 1 to read the touchscreen and interpret the coordinates to determine what event to send, and 1 running VUSB to send the actual event to the host. I just used digital I/O between the two so that the first Arduino could trigger USB events on the second. -- Jon
digitalWrite(13, !digitalRead(13)); // don't know what this is for
I doubt that the intent of this code is to turn on and off the pull-up resistors. I can't imagine a case where that needs to be done.
It seems more likely that the code is trying to turn the LED on and off, which implies that it is an OUTPUT pin. The lack of a pinMode contra-indicates this, though.
So, we must assume that the pin is in it's default state of INPUT, and indeed the code is turning the pull-up resistors off and on. A strange thing to do, in my opinion.
You're right, it's missing a pinMode command. The example sketch in Practical Arduino includes the pinMode command and an explanation of what that line is trying to do.
Basically it's exploiting the fact that you can read from a pin even when it's in output mode, allowing the pin itself to act as a state flag that is inverted on each pass to cause the state to toggle. It just reads the pin, then writes the opposite value of that reading back to it. -- Jon
Manuel, I'm glad to hear you want to give Aiko a go! It's pretty cool when writing sketches with complex timing interactions.
Recent versions of Arduino allow libraries to be installed in two places: either inside the "hardware/libraries" directory inside the Arduino installation, or inside a "libraries" directory inside your sketchbook.
There's lots more information about libraries in chapter 16, in the section called "Writing An Arduino Library".
Also, there's a Google Group related to Aiko and the main developers are all on it, so if you have other questions that's probably a good place to start:
A bias resistor can be added externally as you've done, but the ATmega MCU used in the Arduino also has a handy feature that lets you activate built-in pull-ups inside the MCU itself to save you having to add your own.
Could things be arranged so that when someone "out there" on the internet asked theWAMP server to serve up a particular page of HTML, then before that page was sent, the WAMP server would send "TellMeTture" to the Arduino (over serial link), wait for answer, and incorporate answer in page served?
Sure. What you need to make that work is some pre-processing at the web server end of things to dynamically generate the page that gets sent back. Since you're running WAMP you should have PHP available to you, so rather than placing a static HTML page in the webroot you can put in a PHP script that communicates with the Arduino to fetch the temperature value before sending the page back to the user.
However, there are a couple of gotchas. Firstly it's not so easy to use PHP to open a serial connection to do the communication: in that situation what I typically do (including in my home automation system, which you can see a little of at www.superhouse.tv) is use a serial-to-TCP proxy (I use ser2net on Linux, but there are equivalent programs on Windows) to expose the serial port as a network socket. Then it's a piece of cake to have your PHP open the socket to talk to the Arduino and get the temperature.
Secondly, doing it this way will introduce some latency. Fetching the data live will hold up the page from being sent back to the user, and even if it's only a few hundred milliseconds that can still make the system feel really slow. You may be better off running a separate process that periodically polls the Arduino to get the temperature (perhaps every 30 seconds) and writes the value into some common location such as into a textfile or a database. Then it's a simpler job for your PHP script to fetch it whenever a page is requested rather than talking directly to the Arduino. -- Jon Freetronics: www.freetronics.com
There have been some problems with compatibility between different versions of the IDE and the USB library in this project, but in general I've found that if it compiles cleanly using the example code in the book then the library/IDE compatibility is OK. If you hit the library problem then it fails to compile in a very obvious way.
It sounds to me most likely that you have a hardware problem. One of the tricks with this seemingly trivial circuit is that you have to minimise capacitance on the USB data lines, and using Zener diodes over about 400mW will almost certainly add enough capacitance to stop the bus from operating. Ideally you should use 250mW Zeners, but they can be hard to get.
What operating system are you using on the host computer? If you're running Linux you could try tailing the system log and then plugging in the device while watching the log, using a command something like this:
tail -f /var/log/syslog
Syslog may be in a different location depending on your distribution, and I assume you can do something similar for MacOS but I don't know where it stores its logs. As for Windows - no idea, sorry. I don't have any Windows machines.
What you're looking for in the log file is entries related to USB devices, possibly saying that it found a new device but that it couldn't enumerate it. If you could give that a shot (perhaps on a friend's Linux machine if you don't have one) and post the relevant section of the syslog that may give more clues.
@AK88: you're interpreting that correctly. I don't know if this problem has been fixed in the latest version of the official Ethernet Shield, but with the Freetronics Ethernet Shield you're definitely set. We specifically tied the Wiznet chip enable pin to SS (via an inverter, IIRC) to solve that problem and avoid the need for hardware hacking. -- Jon Arduino Shield List: http://shieldlist.org/
@PaulS and @fells are spot on with their descriptions of the problem and the solution.
As a bit more background so you understand what's going on, SPI is a method for communicating between a master device and one or more slave devices on a shared bus. It uses 4 signal lines, 3 of which (SCK, MISO, MOSI) are common to all the devices. Each slave device then has its own SS (slave select) line so that the master can enable each one in turn to talk to it.
So what's happening in your case is that, as @PaulS pointed out, both shields are using the same SS line so when the TwentyTen asserts the SS line for the Ethernet Shield it also gets a response from the USB Host Shield, and neither of them work.
@fells solution is to change one of the shields to use a different SS line, and then the TwentyTen can address the shields independently and everything will be happy.
As an aside, you may find this site useful in future for finding pin conflicts:
If that is a 5 cell pack, 5 x 1.25 = 6.25. The Arduino external power is rated at 7.5 volt minimum
I think it may actually be even worse than that: NiMH AA cells I've seen are rated at only 1.2V, so 6V total for the set of 5 when fully charged and experiencing *no* terminal voltage drop due to load. Even with the cells fully charged it's going to be very borderline.
@EddyTheJekyll: Probably best to find yourself a 6-cell battery pack if you can: it'll still be marginal, but not as marginal as the current setup.
By the way, do you have a blog post or similar about this project that I can point to from the Freetronics site? -- Jon
Could it be one battery in the set is bad and is introducing battery resistance?
Definitely. That's a fairly common scenario. You see it with any multi-cell battery, such as a car battery: if any one cell in the battery develops a leak or other fault, the whole battery will be rendered incapable of delivering the rated current / voltage. -- Jon
I think @retrolefty is spot on with the comment about voltage dropping under load. Both fully-charged and partially-charged batteries may show very similar terminal voltages when unloaded, but then the internal resistance of a partially-discharged battery can cause its output voltage to drop dramatically when loaded up.
By the way, there's a rule that says any post that mentions a robot should include a photo.
@donone, thanks for the comments on the SMT tutorial!
Yes, it's certainly quite feasible to do it with a headband magnifier. I have one of those as well and it does the job.
I must say that I *love* my microscope though! It's turned out to be one of the most useful tools I've bought in a long time. I've got so much into the habit of using it that I even do a lot of regular (non-SMT) soldering under it, even though my eyes are fine and I can see detail on a PCB perfectly well. Having everything massively magnified so that you can see the tiniest detail lets you spot flaws in joints that you just can't see with the naked eye, and the result of doing hand soldering under the microscope is that I rapidly improved my technique because I became so aware of every tiny mistake or blemish.
It's not just a matter of inspection after the fact, either: watching the joint under the microscope as it's being made is extremely educational. You can see the flux boiling off, watch the trace change colour as the heat travels around it, see the edge of the solder as it wicks along the surface.
The other advantage of a microscope is that you don't have to crouch down so low over the PCB. I'd prefer a microscope that has an even greater physical separation between the eyepiece and the work surface so that I can sit fully upright without hunching down at all, because a couple of hours of assembly is enough to give me a really sore back. It'd be much worse with a headset though. -- Jon