Reference: http://www.meatandnetworking.com/tutorials/creating-svg-files-worth-of-creating-solder-stencils-from-kicad/

* Export solder paste layer from KiCad as SVG file
* Ensure that all pads are grouped individually per square (and not single lines)
* Rescale them to 90 %
* Set the line thickness to 0.025
* Then copy and move a copy of the whole board, to correspond to the panel layout

• Use the accelerometer data and integrate
• Use the GPS on the phone and get the speed from that measurement

To get an acceptable result we needed to combine these two measurements, as sometimes the GPS is quite inaccurate, and sometimes the integration from the accelerometer drifts off.

For the accelerometer we then also made a couple of assumptions (based on measurements of data on the tram and testing the App in progress):

• The tram mainly moves forward, so we only take into account one axis of acceleration for the integration. This ensures that we don’t get additional noise from three different axes, but of course limits the way in which you can mount the phone.
• When the tram moves, the “sideways axis” and the gravity axis of acceleration shakes quite a bit, when the tram is standing still, this vibration is not present. We can use this to detect whether or not the tram is moving or not. When the tram is not moving, we can make sure that the calculated speed goes to zero, and thus reset the integration constant
• When the tram is standing still, we also reset the offset of acceleration, to account for any kind of drift of the sensor itself over time.
• When the tram is on an incline or decline (a hill, a bridge, or going down into a tunnel), we get a bit of an offset so we need to compensate for this.

This added to a couple of other things like calculating means and standard deviations over a certain time window, taking a moving average, resulted in the final App, which can be downloaded from github:

https://github.com/sensestage/Guesstimate-Velocity-Better

Settings which worked best with the Samsung Galaxy S2 phones:


Sensor: accelero
Forward axis: Y
Sideways axis: Z
Gravity axis: X
Window size: 200 Delta time: 10
THRESHOLDS:
Gravity Tresh: 0.05 Gravity MA: 0.8
Still forward: 0.06 Still side: 0.06
Motion forward: 0.1 Motion side: 0.06
Accel std: 0.2 Accel mean: 0.1
Decel std: 0.3 Decel mean: -0.1
Mean weight: 0.95 Raw weight: 0.05
Offset MA: 0.999 Speed decay: 0.99
Mean MA: 0.99 Prec. MA: 0.2


Because a smart phone has a couple of sensors built-in and is capable of uploading data to a remote server, we chose Android as a base platform to work with. However, we needed to find out which phone had the best sensors to do this, i.e. which phones had sensors that were most accurate.

By making a call for help where we asked people to run a program on their phones and send us back the information on the sensors in the phone that the program reported, we got a reasonable overview of which sensors are in which phone, and their accuracy.

The results are listed in the two pdf’s down here:

Overview Android Sensors

Accelerometer characterics

Slick design for using USB, MIDI, CV devices with sensors:
http://www.teenageengineering.com/products/oplab/

http://interlude.ircam.fr/wordpress/?p=229

This one uses another wireless chip:
http://www.jennic.com/products/wireless_microcontrollers/jn5148

Paper on MO-objects

Going from the manual [1], I found out that these options work, mainly the settings for ATA2 and ATA1 are interesting:

Configure the coordinator with:

ATA2 6    // 0b110 : allow associations (bit 3), automatic channel select (bit 2), fixed pan id (bit 1)
ATCE 1    // coordinator enable
ATAP 2    // API mode 2 (with escaped characters)
ATID 7970 // pan id
ATMY 1111 // address of the coordinator
ATDL 1    // destination address low bytes
ATDH 0    // destination address high bytes

Configure the nodes with:

ATA1 6    // 0b110 : use automatic association (bit 3), automatic channel select (bit 2), fixed pan id (bit 1)
ATCE 0    // coordinator enable
ATAP 2    // API mode 2 (with escaped characters)
ATID 7970 // pan id
ATMY 1    // address of the coordinator (or ATMY 2)
ATDL 1111 // destination address low bytes (address of coordinator)
ATDH 0    // destination address high bytes

What will happen according to the manual is that the coordinator upon startup will scan the channels (different frequencies in the 2.4 GHz range) for the one that has the least energy on it. Then it will pick that one.
The nodes will look for a coordinator on any channel that matches the pan ID they have, and switch to that channel.

As a side effect the MY address of the XBee on the nodes is reset, so this is solved by setting it in the node firmware to the desired address again.

[1] XBeeManual

• Connect both USB and the AVR ISP mkII programmer to the board
• Open the Arduino sketch in the Arduino IDE
• Select the “STEIM wireless receiver” from the Board menu
• Compile the code
• This makes a temp directory with the hex file in (e.g. on Linux) /tmp/buildXXXXX.tmp/wireless_receiver_1_4.cpp.hex
• Then use avrdude to burn it to the flash:
  avrdude -c avrispmkII -p m328p -P usb -U flash:w:/tmp/build4971464468714801572.tmp/wireless_receiver_1_4.cpp.hex
• The output will be something like:

  avrdude: AVR device initialized and ready to accept instructions
  
  Reading | ################################################## | 100% 0.00s
  
  avrdude: Device signature = 0x1e950f
  avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
           To disable this feature, specify the -D option.
  avrdude: erasing chip
  avrdude: reading input file "/tmp/build4497645872316412355.tmp/wireless_receiver_1_4.cpp.hex"
  avrdude: input file /tmp/build4497645872316412355.tmp/wireless_receiver_1_4.cpp.hex auto detected as Intel Hex
  avrdude: writing flash (8492 bytes):
  
  Writing | ################################################## | 100% 2.64s
  
  avrdude: 8492 bytes of flash written
  avrdude: verifying flash memory against /tmp/build4497645872316412355.tmp/wireless_receiver_1_4.cpp.hex:
  avrdude: load data flash data from input file /tmp/build4497645872316412355.tmp/wireless_receiver_1_4.cpp.hex:
  avrdude: input file /tmp/build4497645872316412355.tmp/wireless_receiver_1_4.cpp.hex auto detected as Intel Hex
  avrdude: input file /tmp/build4497645872316412355.tmp/wireless_receiver_1_4.cpp.hex contains 8492 bytes
  avrdude: reading on-chip flash data:
  
  Reading | ################################################## | 100% 2.43s
  
  avrdude: verifying ...
  avrdude: 8492 bytes of flash verified
  
  avrdude: safemode: Fuses OK
  
  avrdude done.  Thank you.