11 May 2016
Demo Video
The demonstration video shows the current working functionality of AtomWire+, using cuts of footage of playing the two demonstration games and displaying serial monitor outputs parallel to the manipulation of the circuit.
Final Report
On March 6th we completed the official demo of AtomWire+. Much of the progress was made during the week between the first demo and this final demo, as David implemented the new network protocol, allowing arbitrary messages between the master and slave nodes, and I developed two simple games to demonstrate interfacing with this system. The final report outlines the current state of the project in all its glory. You can find the final report here:
26 Apr 2016
Where are we now?
We are right now able to demonstrate two things on different boards.
First, we can show that our leader microcontroller can talk to different followers distributed across multiple atom wires. That demonstrates the possibility to use more than one base to build connected blocks on.
Second, we showed the basic implementation of the link layer protocol destcribed in the previous blogpost. It shows how the leader searches for all connected followers then selects one after the other. Every selected node receives an arbitrary messages increses the number of the lowest byte by one and then sends it back to the leader. This returnes message is then sent to the next follower and so on.
Where do we go next?
For our final presentation we plan to implement a network protocol based on 6LoWPAN and two games. One will use blocks to build a path to get to the goal and the other one uses different types of blocks with different sensors attached to it to activate different action in the game.
25 Apr 2016
We did a thorough study of the exiting AtomWire protocol based on the 1-Wire protocol (described in the DS2413 data sheet). The outcome is an AtomWire Specification that can be found here and a table containing a summary of the different times for the protocol described in the data sheet and examined from the AtomWire code.
This examination showed us two issues of the existing protocol. First, the timing for every iterations/rounds of the protocol is of arbitrary length. Every iteration starts with the reset/presence pulse sequence. This is needed to synchronize the followers with the leader. Because this pulse can happen at any time the followers always have to listen on the wire and it’s hard to do independent and inverleaving calculations on the followers. Second, every command after the reset/presence pulse and the selection of a node has different parameters and thus takes a different amount of time. Additionally adding a new command requires the addtion of all the timings for this command to the code of the leader and followers.
The AtomWire+ Protocol
To overcome this issue AtomWire+ implements a time-slotted protocol with messages based on the existing protocol.
Time Slots
There exist two time slots: the search time slot and the message time slot. Every iteration of the protocol starts with the reset pulse by the leader following a presence pulse of the followers. If no presence pulse is received by the leader, he will continue to check for followers with the reset/presence pulse sequences until a follower shows up.
Search Time Slot
If follower(s) show up the leader starts an search (sends command 0xF0) to find all the followers and their addresses. The search is the same as in the 1-Wire protocol and described here. Every search iteration will take 14400µs (14.4ms). If a follower is excluded until the next iteration it can do other calculations or go in a low power mode until the current time slot expires. The search is finished when all followers on the wire are detected. Now at least one message time slot follows before the next search can be started.
The search is repeated in a specified interval to detect added or removed followers.
Message Time Slot
This time slot is used to exchange messages between the leader and one follower. After the reset/presence pulse the leader selects a follower (0x55 followed by the AtomWire ID of the follower) and then does two message exchanges. First it sends a command (1 byte) followed by a message (8 bytes) to the follower and then it issues another command (1 byte) indicating to the follower that it can reply with a message (2 bytes). This concludes a message times slot and takes 16080µs (16.08ms). In the next iteration the leader selects another follower on a fair ordering basis. Followers that don’t take part in the existing time slot can do other calculation or go to sleep after the selection command and check again after the time slot is expired.
Messages
The transmitted messages are 8 bytes (64 bits) long and can theoretically contain arbitrary information. To make parsing and error detection of messages possible we introduce the following message format.
msb 7 6 5 4 3 2 1 0 lsb
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
cmd-|-----------content-----------|-crc
For error detection the last byte (least significant byte) is a CRC-8 check value (like in the 1-Wire protocol). The most significant byte encodes the command indicating to the receiver how to parse the content of the message.
This specification is a “work in progress”. The most recent specification can be found here.
18 Apr 2016
This past week we’ve been testing the circuit with various different components in an effort to improve node detection.
Through this, we’ve upped the one-wire node limit from 3 nodes to 5 nodes.
On Wednesday, April 13th, I took a closer look at the power supplied to the ATtinys. Using a multimeter, I saw that each operates using about 9 mA. When they are powered by the same 5V power supply, a little over 50 mA is used on average.
Also, I tested using between 0 and 3 buffers on the line. Even when powered by an external supply, only one node can run successfully when no buffers are used. Even with two buffers, only one node works all the time, while 2 will have long gaps between successes.
Using the 3 buffers as usual with more than three nodes resulted in some error in detecting nodes, with a couple nodes being detected periodically.
This problem was amplified the more nodes we added. At six nodes it could detect node A2 sometimes, but not the rest. If four nodes were left on the line long enough, none would be detected anyore.
I then switched from the external 5V supply to the Arduino’s 5V pin. With all nodes powered, communicating with up to four was possible, and any more would lead to errors. At six nodes one address was corrupted, followed by eternal “No further slaves detected” spam (from now on refered to as “NFSD spam”).
One of the reasons this setup may have worked slightly better than with the external supply was that I changed to a 1 MOhm pull-up resistor on the one-wire line. A the very least powering more than 3 nodes with the Arduino was proved posible.
However, when powered by the one-wire line (with the 5.1V Zener and 10 uF capacitor), plugging in a fourth node causes a NFSD spam. Looking at the voltage provided, we could see a significant drop.
What sould be a 5V line drops down to about 2.93V across the capacitor on average when 3 nodes are connected, still within operating voltage, but drops down to 2.3V with 4 nodes, significantly lower than the necessary 2.7V.
Next I tested switching out the capacitors and diodes, as with then-current circuit the one-wire line was incapable of powering all the nodes itself.
Changing capacitors did not provide very useful results. Decreasing or increasing capacitance caused the circuit to work worse if the new capacitance differed too much from the 10uF used, likely due to the timeing constraints dictated by the software.
Changing the diodes again, however, was a breakthrough. Changing from the 5.1V Zener to a different diode labelled 1N5817 resulted in the circuit surviving a fourth one-wire node.
Adding a fifth node causes a pattern of a couple nodes being detected, but adding a sixth causes NFSD spam and the system recovers once nodes above 4 are removed.
The next day we did tests on adding and removing nodes in groups. Removing nodes was never a problem, as confirmed by these tests, but adding more than one node yields worse results both the more nodes that are already connected and the more nodes you are trying to connect.
For example, with no nodes connected, one or even two blocks can be added without any problems, but with one block already on the line adding two has complete success 8 out of 10 trials, and with no blocks on the line adding three is far less successful. Adding all four at once successfully is possible, but only happened once out of 10 trials and missed node two on the first pass for that trial.
The problem may be related to the timing of adding the group of new nodes.
We also used LEDS connected to nodes via transistors to visualize and compare the states of live nodes compared to “dead” (undetected) nodes. We then took an oscilloscope image of the pin output of a live one compared to a dead one. The dead node may actually be stuck in the reset state. The voltage fluctuations of the dead node are likely due to the fluctuations of its VCC input due to the one-wire voltage not being constant.
Yesterday I played around a bit with the reed relays. It would be useful to add switching between branches of nodes to the circuit so block configurations can be detected with multi-node blocks. However, so far connecting a relay to a node consumes too much power, as each requires about 10mA and 5V (around 3.75V minimum) which can only be supplied when only two nodes total are connected.
Finally, today we got 5 nodes working together simply by adding another op-amp buffer to the line. While having so many extra bufferes connected to each line may be problematic, even on the master’s side, the circuit has so far worked flawlessly.
13 Apr 2016
As of right now AtomWirePlus can only be described as buggy and severely limited, but at least works when limited to three nodes. The “bugs” with our current implementation are as follows:
- Adding a fourth node causes the system to spaz out with a stream of “No further slaves detected,” with some rare successful detections of one of the nodes occuring after a ridiculous number of search cycles. Removing the fourth node does not fix it. It must be removed and then the original three nodes removed to be added again successfully.
- Adding multiple nodes at once can cause one or more of them to never be successfully detected until all nodes are added and removed individually.
- When we tried powering all the blocks directly with an external supply, the system similarly had problems with node detection. As more nodes were added to the system, fewer were detected.
In the midst of these setbacks, though, we have determined some things that do work. For example, the system works with one-wire power when using a 10uF capacitor and a 5.1V zener diode instead of a normal 1N4004 diode. In spite of the previous group’s success, we could not get multiple nodes functioning with the 1N4004 diodes. Additionally, by adding a 500 Ohm pull-up resistance between the master’s 5V supply and the one-wire line, the success rate when connecting nodes to the line appears to have increased.
The system so far is successful when only up to three nodes are connected. When added and removed individually, the nodes are almost always detected. When two nodes are removed and readded, sometimes it does not detect one or both of the nodes, but detects them both more often than not.
Currently we are trying to determine why the number of nodes is so limited and what needs to change to make the circuit capable of supporting a sizeable number of nodes on an AtomWire line.
04 Apr 2016
Our project, AtomWire+, aims to improve the existing AtomWire project, but to do that we need to develop our understanding of the original design and process. Thus, our project begins with a thorough read-up on the existing report and specifications and attempting to recreate the original, operational circuit.
AtomWire is a system in which a master node both powers and communicates with a chain of slave nodes over a one-wire bus. Essentially, this project involves designing a system that can send meaningful signals between many parallel nodes and the master node while still keeping all slaves within operating power. The master needs to be able to detect adding and removing nodes, and the system must ensure proper time division between charging and communication and that devices do not “speak” over one another or during charging. AtomWire is intended to be embedded into toy building blocks to create an interactive gaming interface. Our goal for improving the current system is to create an API that developers can use to easily control a 3D game world using these building blocks.
Our first roadblock in understanding the system is the OneWire search algorithm. Much of the existing software is a mimicry of the existing Dallas OneWire chips’, as expected considering AtomWire attempts to mimic the OneWire system on a more capable general-purpose chip. This algorithm is the method that currently allows the master, a ATmega328P microcontroller, to detect slaves, ATtiny45 or ATtiny85 chips, connected to the OneWire bus. Understanding how the master and slaves communicate is an integral part to understanding the original project as a whole.
Additionally, understanding the original circuit design has not been easy. Currently we are setting up time to meet with the original AtomWire creators and see the original circuitry for ourselves, but in the meantime we have been making due with hints from the other resources. The schematics in the original’s report shows a simple circuit with the bus going to both an I/O pin to read from and write to the wire and a diode to feed power to a capacitor placed between the VCC pin and ground. The documentation specified a 10uF capacitor was used, which we are using for our circuit for now, but was vague about the type of diode. The original documentation was very vague about the placement of Op-Amp buffers, apparently used for impedance matching with the pins. Realistically, these Op-Amps would also need to be replaced with simpler, more specialized buffers that would function with the available voltage provided instead of an external source.
A previous PCB design has suggested placement of a zener diode instead of a normal diode. Our trials with the two suggest the 5.1V zener diode better prevents backflow from the capacitor when the bus is low and the master is expecting input. While fairly certain our circuit should work, and at the very least provides power to the ATtiny, attempting to run the original software with a single node fails, with no reply from the slave to the master’s search no matter which pin we feed the signal to.
This week our goal is to get a circuit working as the original did and have a PCB design ready by Wednesday night for submission. Once our updated proposal is complete we will post it, which will give a better idea of our vision/endgoals for this project.