Upgrade a Tron Identity Disc with: RPI Zero, WS2812b LEDs, Sound, Gyro/Accel, USB storage/networking/charging, Wi-Fi, haptic feedback...
Already have an account? Log in.
To make the experience fit your profile, pick a username and tell us what interests you.
Last summer, my brother-in-law Wayne saw some videos of customized Tron discs -- and had the idea to upgrade a disc with lights and usb storage. A simple, usb thumb drive, arduino, EL-Wire, LEDs and AAA batteries were looking good -- until I picked up a Raspberry Pi Zero and found: WS2812b, LiPo, and ESP8266 SDIO WiFi.
Internal power, full brightness LED test:
...
Parts layout & wiring has made a lot of progress. Power switch is working. The halves still close.
In the pic below:
I investigated realtime and deadline schedulers to see if they could improve reliability of WS2812 LEDs connected to SPI1 on a RPI.
In short: no.
Additionally, the bcm2385 main & aux SPI drivers definitely need some work to support bit lengths other than 8.
Surprisingly, I found that USB (or the USB network gadget) has a huge impact (I read USB on RPI makes use of a special high priority, fast interrupt).
Activating the network, or a data transfer of several kB causes major glitches in the SPI/LED timing - until the traffic dies down.
More details below...
First: Many Thanks to Tim's Blog for great work on Understanding the WS2812.
Short version is, I now have a basic & good enough WS2812b SPI driver in Python, working with the RPI SPI1. But it was pretty rough. I ran into some really weird issues...
Read more »Networking the PI through Windows isn't a primary goal of this project -- but not having network access (or even worse, having it intermittently) makes setting things up much, much harder. On top of that, a flaky network setup messes with Windows' cloud sync -- making some apps unresponsive, lock up, and possibly lose changes (bad if you're trying to take notes).
The problem(s) appears to be mismatches between the linux dhclient and DHCP server in Windows Internet Connection Sharing (ICS), and a flaky RNDIS driver/implementation.
This could be avoided in various ways, but ICS seems like a nice, simple way to go (if it worked better).
The workaround version is:
First boot: Wait at least 2-4 minutes for the PI to give up on dhcp and assume a link-local 169.254 address
Repeat: down-up the interface / disconnect usb / reboot -- until dhcp succeds
(it may succeed the 2nd time due to starting from the link local address & netmask?)
(but may still take a couple minutes after the login prompt appears)
Later boots: will probably still be slow because dhcp is intermittent, but it may fall back to the last saved dhcp reservation settings (if the address is not in use).
More Details below:
---------- more ---------
PreReq:
Setup usb gadget /boot/cmdline.txt :: dwc2,g_ether g_ether.host_addr=xx:xx... g_ether.dev_addr=xx:xx...
Change device driver to RNDIS
Setup ICS
First: how to spot part of the problem in windows
Open "View Network Connections" (typing in the start menu to search seems most consistent).
Windows may disable the RPI network device driver: re-enabling will fail, networking will not work. Then the RPI must be disconnected from USB and rebooted. (if it's not disconnected, or if you tried to re-enable it -- then windows may also require a reboot)
(the windows event log will show repeated 10400 NDIS "The network interface ... has begun restarting." -- "Reason: The network driver did not respond to an OID request in a timely fashion.")
Second: getting the right commands, to trigger a dhcp request
This first requires adding to /etc/network/interfaces
(otherwise you will get an error "ifdown: interface usb0 not configured")
allow-hotplug usb0 iface usb0 inet dhcp
Then, this command will restart dhcp on the interface
sudo ifdown usb0 && sudo ifup usb0
it will also show the output of dhclient. A typical result looks like this
DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 12 DHCPREQUEST on usb0 to 255.255.255.255 port 67 DHCPOFFER from 192.168.137.1 DHCPREQUEST on usb0 to 255.255.255.255 port 67 DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 13 DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 19 DHCPREQUEST on usb0 to 255.255.255.255 port 67 DHCPOFFER from 192.168.137.1 DHCPREQUEST on usb0 to 255.255.255.255 port 67 DHCPACK from 192.168.137.1 bound to 192.168.137.118 -- renewal in 236 seconds.
Note: dhclient recieved two offers (from 137.1) but did not take the first one -- I've even seen it refuse 4 offers...
Unless it works immediatley -- there always seems to be 4 discovers before a request...
Where or how are the requests/offers lost or corrupted?
Future: there is a tool called dhcpdump that logs all dhcp traffic on an interface
Space inside the disc was roughly estimated by examining pictures and video, and similar projects.
http://www.instructables.com/id/Custom-Tron-Disc-Mod/?ALLSTEPS
https://www.flickr.com/photos/blackfeathers/sets/72157625208305212/
LED: The RPI can drive WS2812b LEDs with DMA https://github.com/jgarff/rpi_ws281x
This conflicts with PWM sound, but we have options:
WiFi: The RPI has support for a 2nd SD / SDIO port, and the ESP8266 has a SDIO bootloader mode. https://hackaday.io/project/8678-rpi-wifi
The just released Pi Zero W (if/when you can get one) may make this redundant. But the ESP8266 may have future potential here as a scriptable WiFi/SPI/GPIO expander.
Battery: The "Custom-Tron-Disc-Mod" project above stated AA would not fit but AAA would.
But for this project, with more LEDs -- a LiPo can have a larger capacity (for more runtime and brighter lights), and fit more compactly (allowing more peripherals).
Early plans were to fit the battery in the battery area - possibly removing the screw for the USB jack.
But latest plans are to put the battery in the largest open area - to eliminate sharp corners that could puncture the LiPo.
Other technical hurdles:
Disassemble the disc, remove and keep internal components.
The top half has the C ring, the bottom half has the battery door.
Trim the 6 wedges from inside the soft plastic ring - be careful to not damage the lip on the inner edge that holds the ring in place.
Make room for the outer LED ring on the top half of the disc:
Completely trim away the 6 short spurs (by the screw posts)
On the bottom half of the disc, make room for the RPI and outer LED ring:
The battery will be placed in the largest open area.
For the RPI: trim down the post and screw mount where the bump sensor was.
Cut a notch for the LED strip to go around the outside of the RPI.
To help the RPI fit under the C ring: cut a few mm down into one rib.
At the other end of the RPI, similarly trim down one rib of the screw support.
Also trim down the inner side of the 4 ribs that stick up, to give the C ring more room.
Dan Rogahn
Christoph Tack
Ken Yap
blinkingthing