Networking and Communications

29 November 2017 | By Casey Evans

“A brand is no longer what we tell the customer it is--it is what customers tell each other it is.”-Scott Cook, founder of Intuit

Assignment

Group Assignment: None.

Individual Assignment: Design and build a wired &/or wireless network connecting at least two processors.

Class Notes

Other People

Natalie gave an overview of AppInventor. Get into JSan to post requests on the web. Neil says setting up a web socket is easier than we think. Priyanka writes instead of documenting in the web page, which I feel is valid but does make more work. Or I guess she could scan the pages like I did with her notes. But that would be an awful lot of pictures. Cobbler = shoe maker. This week is radios. Work backwards rather than forwards. Be mercenary about the steps. Soma. Matlib and NumPy. She has a cool window blind. It’s made of kirigami. Elizabeth Carre. Burhan Azeem. Backbone then Angular then React. Those are all frameworks for JavaScript. View is what you see. Controller changes inputs to model. Neil hates the framework but it’s important to use them because it facilitates multiple developers work together. The problem is it abstracts you away from the code. http-server(-with-auth) by npm. How to run your own web server. We should have overall designs of what the project is going to look like. Max Allen isn’t here. Vibha Agarwal also not here. Eghbal is here. Point grey camera. High frame rate makes it hard to write to the hard drive. Sam Calish’s Chronos is similar. Krontech Chronos camera. Used an SSD hard drive to attach to the computer to solve the problem. LabVIEW requires a $500 license. You have to write your own code to do hard things though and you end up not really using LabVIEW. It has a huge scheduler overhead. Opencv is a nice image processing library. Be paranoid about the pipeline. 1Gflop expected for 1 million pixels. Opencv for things that are algorithmically complex. C for simpler things. Oh. I just realized I can look at Neil’s code to see how to set up a Google custom search. Eghbal’s final project is music modules. Switched-On Bach is a great album. James Fletcher did one on an ATTiny44. A joog instead of a moog. Eghbal’s project is a combination of digital and physical sound making things. Casey Evans. Webserial chrome web fiction, chrome serial can work in a browser. List all files. Serial server save to desktop clients allowed to address and npm install serialport, install websockets, run as rot for permissions, then you can open the server, port 1234, minitermpy embedded programming, baud rates wrong, rx.py, look in oscilloscope and check bit rate, shimming in new models is possibly better at reliable timing, a programmable lamp is plenty for scope, he really likes my stream of consciousness notes (yay!), Agnes. “I haven’t decided if I love or hate [the site] I think it’s both”-Neil. She did a C++ rabbit speed thing. ASCII art program perhaps (feature seeking). BUNNYSAYEVERYWORD is a twitter bot. “The internet was surprisingly unhelpful.” -Agnes. Julia Ebert. Light controlled flappybird. Used Racket (nostalgia since she learned to program in it). Python (lisp without the parenthesis) and PyGame (really an sdl wrapper for media stuff). Tomas Vega. Kaspar made a control panel for his ornithopter. Set G range of accelerometer. Threejs scene description. Nodejs.

Neil says that the point of this class is to get rid of the sentence that “I’m MechE so I don’t know how to program.” As well as “I’m CompSci so I don’t know how to make.” But all this messy compsci guru stuff is intimidating.

This Week

Work not by demand on your time but by the supply of your time. Recitation one floor down. Sam will cover the XMega. PSoC. Processor core with soft modules around it. Arm programming. Build a wired or wireless network connecting at least two processors. Many reasons for this. The obvious one being talking to something that’s not where you are. Another is an interface on a device for a device somewhere else. Parallelism. AVR runs at 10s of 10^6 cycles per second but costs 10s of cents. Also can help with performance. Modularity is another good reason (separate subsystems to test independently). Interference. One circuit with high noise and all that is hard but if you have separate boards for each system then you can limit interference. Start with simple networks and end with radios. RS-232. Extensions for multiple devices. Bridge board, Tx and Rx lines onto a bus. Tx to Rx. Each board connected to the Tx and Rx lines. Tristated Tx. Give an ID to each board. Each board listens but only one board matches the message, when it hears its ID it changes to an output and sends a message. Simple serial bus for no more than 10 processors probably but they should be pretty easy to understand. “It’s really trivial to make a serial bus.”-Neil. Have to be well behave to take turns talking. I2C is a standard protocol. RS-232 is asynchronous, you just blurt out the data. I2C has a clock line as well as a data line. It’s a standard protocol for interprocessor communication. Prioritizes who gets to talk. Accelerometer speaks SPI or I2C. Atmel has app notes. TWI or USI modules. TWI is the same thing as I2C (Philips IP battle). Bit banging it where you use software to turn pins on and off. Programmer speaks SPI. Roughly equally useful SPI to I2C. SPI in circuit programming, I2C device networking. Sociotechnical history no deep reason. SPI is faster at really high speeds. If he controlled both sides Neil wouldn’t use either. USI section of the ATTiny44 data sheet for more info. V-USB is USB in software. An extreme version of bit-banging. It’s slow (USB 1.0) USB has tight timing requirements but it adaptively clocks in software by listening to the host. USB to FTDI project has been done. With MegaU2. LUFA is a good third party library using AVRs with hardware USB to implement various devices. Bus v network: network designed so anybody can talk to anybody and (ideally) know where each other are. Mac how you decide who can talks…oh, there’s loads of OSI layer.

Physical media – wires or no wires, differential is difference between two lines, single lines measure high or low, power line link capacitively (like radio somehow), sharing line by tristate to connect or disconnect from the line, ethernet used to be more important (chips simple but physical is complex, sth about magnets), FCC regulations on radios and spectrum control, ISM is industrial/scientific/medical open season spectrum, microwaves interfere in a junk band, 900MHz, others are less crowded and good to use, BLE is to Bluetooth is as JavaScript is to Java. As in they have nothing to do with each other. BLE is Bluetooth low energy (models 4 and on). Services you publish and subscribe to. Event driven instead of listening constantly. Not sure how that really works. Nordic semiconductor. “It’s easy to forget about light.” That is IR. Not regulated so it’s pretty great. Blink lights and read that as data. Lifi, wifi but blinking lights. Ultrasound is another way to send data. Light needs line of sight. Sound doesn’t need that.

Modulation: PCM (pulse code modulation), PPM (where the pulse occurs), OOK (presence or absence of a signal), FSK (two freqs, one for zero or one, needs a radio for more than one freq), PSK (change phase, only needs a radio at one freq but you need a reference local source to understand), QAM (phases and amplitudes to store lots of bits), spread spectrum (modulate to look random), DSSS (uses random noise), goal is to use bandwidth as effectively as possible, The Comminications Handbook by Gibson.

Channel Sharing: who gets to talk, Aloha you try and if you collide you try again, master-slave has one person tell when to talk, token ring token can get lost, CSMA how wifi and ethernet work (cocktail party, listen and if someone else is talking you don’t talk, pause in silence for a random backoff time before starting to talk; fails if network heavily loaded), CDMA (spread signal to not interfere with each other), MIMO (antenna thickets to steer the beams to get them spacially localized).

Error correction: expect to make errors so add redundancy.

Networking: there’s a good book on it, he’ll fix the link, topology to get from one point to another, internet engineering task force, IPV4 moving to IPV6, packets have a structure and IPv6 has a larger address space, NAT reuses addresses, unrouted private space you can use and assign yourself, IP is address on a letter, UDP adds ports (rooms in the building), TCP splits a big message into small messages, http is tcp to port 80, telnet, sockets are a standard protocol, JS and Python easy to talk to sockets, C is harder, IP over serial dates back to modems (Slip)

Radios: ARRL Handbook, oscillator to send signal, mixer to modulate data, low noise amplifier to receive, intermediate freq stage for partial amp, intermediate signal, filter baseband data. Picture a heavy chain and a skinny thread connected, vibrating thread will reflect back—illustrates need for impedance matching. Antenna gain focuses energy. Single chip radios. IS1871. BLE. System in chip. ~$7. Speaks a simple protocol. Antenna is happier if there’s nothing underneath it. Speaks simple serial. Nordic BLE sniffer. Castellated so pasted on the side of the board. Standard services. Event driven model. nRF24 has all kinds of great parts mixed in. nrf52. Care about it because it’s a very fast ring oscillator. Good radio performance. It’s a general-purpose processor that happens to have a radio. Sam is writing a page on using the nrf52. Requires a new toolchain and all that. Long term goals. Wifi is a power pig. 100s of mA. Requires a big regulator. TCP can go in either direction. Software radio – bit bang radio in software.

Takeaway – at least get the serial bus. Aim it at your final project. Not enough for everyone to have every one. ARM programming, nontrival learning curve.

Training Summary

None. But I did go to recitation this week.

Recitation notes: Try reflow soldering. Sam 2012. Slows when scaling up. Neil’s code works in a blocking fashion (nothing else can happen while it’s working). Try to write non-blocking code. Ring oscillators page. LPC1768 is a cool chip but $55. Peripherals at a lower clock perhaps (ring freq lower than running freq). XMega. Natural progression from ATMega. Better clock speed. Neil likes to overclock them. How to program, how to write the code for it, how to compile the code, how to get the code on the chip. Choose chips that are used a lot (cheater method). Ex adafruit uses NRF52. Single cycle instruction. E series ~$2, smallest version (lowest cost and pin cost). First number is number of memory, last number is footprint. A series is high performance. Atmel Ice or mk2. PDI protocol. Hello World page for XMega by Sam. Atmel Studio recommended by Jake. Quadrature Decoding, better ADC, USART talk to the host without the CPU doing something. NRF has PPI programmable peripheral interface. Event system is the equivalent in XMega. NRF has an event system too but Sam isn’t sure what exactly it’s place in the universe is. Offload computational things to hardware peripherals. All pretty similar with slightly annoying differences (different XMega packages). PSoC and ARM cores. ARMs have way too many options (just slightly different – what is its purpose in life?). SAMD21. adafruit feather line. Question 0: Why? Why go to ARM? XMega doesn’t have radios. Hard limit at 4GHz? Limited by transistor size perhaps. 2 core processor should have a little OS but it’s just the Arduino window. Embedded Python and embedded JavaScript still run a C interpreter. “It’s a wild world of arms.” -Sam. Header files for bit fields. Black Magic ARM replacements. OpenOCD on chip debugger. Uses bit twiddling. BCM2835. High Sierra sucks apparently. I don’t know what it is. “ssh into it.” Bootloaders come with assumptions for a particular dev board. Pogo stick connectors. Tag connect header has serial pins on it. PSoC (programmable system on chip). Have to do it in Windows on the PSoC system. PSoCs come with a dedicated programmer that you can break off later. Use Cypress’s stuff (they make PSoC). “I’m paralyzed by choice.” -Sam. Run Wine (Windows emulator) to work on Linux. Collaborative clocking by Jake. Lattice FPGA company. Google’s Tensor Flow. Tensor processing unit. Bing runs on FPGAs. Verilog is a hardware description language. Really fast signal processing. Add a multiplexer as a peripheral. Works but adds time. Run 16 servo motors with one GPIO (SparkFun).

Assignments

Individual Assignments

So. I got my hands on a Bluetooth module. But that's about it specific to this week. I also spent time working through getting the serial connection to work (see week 12) and cleaning up my output week to be a bit cleaner and better documentation. But the real culprit here is the massive paper due this Friday that has taken me more hours than I'd admit and is still only 11/20 pages in the works and my signal processing project (where I was able to write 11 pages in only a few hours, go figure). Point is, weeks 7, 9, 11, 12 and 13 are all kind of intermeshed for me right now and I will be taking the weekend to sort them out (after the paper, project and pset have been turned in and forgotten).

So it turns out the module I grabbed (the nRF24L01+) really doesn't do BLE as I thought it would. Or if it does, the datasheet isn't very helpful with it and I, with my limited experience, would not be able to pull it off in a reasonable amount of time. So I grabbed a RN4871. This chip wants 3.3V when using FTDI, so I'm thinking to just make a step down voltage divider so I can keep using my 5V FTDI (which I need to buy off Gavin or somehow otherwise aquire). But I'm not sure if the Tx and Rx lines will complain about that. I think for the Rx line I'd have to make sure that the 3.3V will pull up to 5V on the other end. Maybe I only need them to program though in which case I don't need to worry about anything except power, which the voltage divider should work well for. Next step is to read the datasheet so I'll let you know.

Okay, so the User's Guide is here. The other link is the datasheet which wasn't especially helpful. But moving forward I can't find a 3.3V FTDI so I'll try to make it 5V compatible with a voltage divider and an opamp. It's been a while since I've used opamps but here's a simulation I did to see what I would need from the BLE Tx pin to the FTDI Rx pin:

The ground can be common and the Vcc and Tx from the FTDI can be stepped down with a voltage divider. The datasheet says it can operate from 1.9V to 3.6V so a 499ohm and 1kohm voltage divider (the parts available) which gives about a 3.33V output should be fine. I did a simulation to check:

In order to figure out the configuration of the opamp I needed to use a pin diagram. THe one for the fablab opamp is shown below:

Now to draw up a board and print it out. Also, just for reference, I like this version of the fablab inventory. Right now I'm reading through the BLE documentation for App Inventor. I think the way this works is that I could send the BLE commands from the app and then write to the Tx line which could go to the Rx line on the ATTiny controlling the LED bulb. Not totally sure there. I just ran that by with Natalie and she said that's pretty accurate. I can also use GPIO pins. It took me a bit to get the layout working for the modified 5V FTDI compatible chip (at least, I hope it's FTDI 5V compatible - I worry that the BLE Tx line might get pulled up by the opamp but I don't think it will matter too much - at worst it will bring it to 3.3V probably which the 3.3V FTDI would have also done). Well see. I'm an experimentalist and the time has come to try. Actually, I not really either but I think I should just try it rather than worry about it. Well I machined it and the size is just ever so slightly/majorly off that it won't work. And I accidentally ended Priyanka's job while it was calculating so I'm letting her have a turn while I debug. But Niki had a 3.3V cable so I'm going to just try using Neil's native board first then. If it helps my almost board was:

Remember that the scaling is a bit off for the parts that came from Neil's board originally. The parts I ported from Eagle were scaled as I set them. Oh well, that would take time to fix. I'll see how the original board works with a 3.3V cable. I did find the ratio Neil's parts were off by at 1000 dpi. It should be 0.614585 in tall. So I tried that and it was giving me funny issues with the traces so I left it at 1000 dpi and had the same problem. Geez, I gotta learn from my mistakes. And the lab's closing again so I'm going to go home and get some CADing done for tomorrow (bulb, lampshade, stand) and maybe start working with App Inventor. I may have to tell my advisor that I can't come in tomorrow morning. I dunno. Such stress. Very wow. So I did a lot of sketching out things and

Okay, so after much troubles I was able to build the Bluetooth board Neil laid out. Looks great, right?

I plugged it into my computer with FTDI and was confused for a bit until I read the user's manual a few times with Mike. I used PuTTY as a terminal simulator to talk to the thing. After a bit of flopping about I discovered typing $$$ into the terminal gets you into command mode with the BLE. After that you can type commands and hit enter to send them to the device. A good start is the command '+'. That activates echo so you can see what you're typing. Then 'SS,C0' enables the 'UART Transparent service' which is basically how the thing works. You can name your device with 'S-,string'. I called mine ILoveLamp since that's what my roommates have been calling it. Microchip has two great apps for development: SmartDiscover and SmartData (which you need to search in the app store with "Bluetooth Smart Data." These are Apple apps. They look like this:

I'm not sure if they have Android equivalents. The first one finds your device and the second one is a little terminal where you can send messages back and forth. I did that a bit. Nearby BLE devices come up on your screen like so:

Then you just tap to connect. And you get a screen like this:

And when you change the name of the device with "S-,name" it can look like this (note same UUID):

You can send the device data via the SmartData app. I sent a few messages that came through. This is the PuTTY terminal simulator output of what I sent:

Then I tried out the pin setting in the command line. The pinout of the RN4871 is:

I was switching pin 1_2 which you can do with '|O,08,08' to set and '|O,08,00' to reset. There's a table I still have to see if I can enter command mode from the phone terminal, figure out how to send things back to the phone (ie get to the serial terminal of the device) and how to get it to work with App Inventor. I think my networking segment might be to connect the Tx on the BLE to the ATTiny just to see hello echo, but I'll look into that when I have a working lamp. Okay, so sending it '$$$' via the app doesn't cause it to go to the command mode.

In looking into App Inventor I found this helpful site. And it's been a while so I'll remind myself of the BLE documentation. This also might be helpful. I started making the app with the notifications and connection settings. Still trying to figure out reading and writing. Mostly I worked on the relay and logistics of the physical part of the lamp. I'll come back to Bluetooth after I finish updating the documentation.

Okay. I'm looking more into the User's Guide now to see if I can figure this out. I want to be able to send it commands from the phone if possible. D gives he device information which I will need since app inventor's code uses MAC addresses to connect to BLE. This means I'll also need the &C command which will make my device use the MAC address instead of a random address. I'm not really sure what all that is about. And I plugged it in backwards to the FTDI and I think I've killed it. FML. 2 hours later (because I'm much less competent than Neil), I have a second board that works. It's MAC address is D88039F75654. Don't plug these guys in backwards. They are not fans. I need to do some back tracking to explain other things but for now I'm going to jump ahead a bit because I found this great YouTube video to help with AppInventor and BLE. I also found this site very helpful in understanding how BLE works. Here's another link I found helpful.

And now I'll go back. So fun fact about the new board. It can talk to my phone when I type in the terminal emulator. So cool! I think it was one of the settings on my other board that I was playing around with and didn't understand that was preventing me from talking to the phone using the other board but now I'll never know. Anyways, here's a picture of the SmartData app listening to the BLE talk to it:

That whole setup looked kinda like this by the way:

In preparation for switching my lamp I modified the original BLE board to accept two pinheaders (with much soldering patience). That new board looked like this, though I eventually added hot glue to the pin headers and FTDI headers:

I used the new skill I learned a few days back from Natalie's friend to check electrical consistency and make sure my board wasn't shorting. Even under the microscope it was kind of hard to tell. Anyways, after reading those resources above I updated my app (detailed in week 12) and was able to connect to my BLE via the app. On the terminal side it looked like this:

Super cool. Then, as I tried to figure out how to flip the pin, I read in the user's manual about running a script that would tie a handle to setting a pin. I set that up but I don't think I really understand how to run commands and a script at the same time. You might not be able to. That is something I still could try messing around with. Anyways, it took me a bit but I finally figured out what handles were by learning about UUIDs and characteristics and services. There are some good references in the links above, especially this Nordic site and this textbook site. I ended up defining a local characteristic as a read, write and notify characteristic (since that was the example and I knew I wanted reading and writing). I'm still not sure about notification but I figured it might not hurt if I don't use it. I also don't understand the difference between write and write without notification. It might be one of the sources of my problems in actually flipping the pin. Here's a picture of the list of my services and characteristics (listed using the command 'LS':

When I used the new app I developed to try to write to my characteristic, I was able to see the write request in the terminal:

I was curious about the threes and tried many different numbers and strategies in the app but still got them in the values I was trying to write. Not sure what's up with that but I can send and recieve stuff from an interface I designed. Here's a picture of the terminal after I went a bit deep into the 'why are there 3s' question:

It's been an interesting project and I look forward to working with Bluetooth again in the future.

Group Assignments

None.