https://wiki.emfcamp.org/2014/w/api.php?action=feedcontributions&feedformat=atom&user=JontyElectromagnetic Field - User contributions [en]2026-04-21T13:36:36ZUser contributionsMediaWiki 1.39.6https://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3811TiLDA MKe2014-11-28T20:15:27Z<p>Jonty: </p>
<hr />
<div>[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
=EMF 2014 Badge= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards. We designed an Arduino compatible platform to allow easy reuse and access, and have published all code and design files.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==My badge is broken!==<br />
Due to the aforementioned supplier issues it is possible that you may have received a faulty badge, or it may have been damaged by connecting the battery backwards. If you badge will not turn on when it has been plugged in with a MicroUSB cable (and the power switch on the back is set to "USB"), or something else seems wrong with it, please email [mailto:badge@emfcamp.org badge@emfcamp.org] and we'll try to fix or replace your badge.<br />
<br />
==Basic post-event features==<br />
We made sure that the badge has a few features to play with once the event is over. More will be added over time as attendees submit changes to us.<br />
<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
But of course the point of the badge is to modify it and use it for other interesting things! The following sections describe how to update the firmware on the badge, how to use it as a simple arduino, and how to write your own code for the main badge firmware.<br />
<br />
==Getting help==<br />
The EMF 2014 badge is a complex piece of hardware and software, however remember that you can just treat it as an Arduino if you find it all too daunting.<br />
<br />
If you get stuck and need advice, there's an [http://webchat.freenode.net/?channels=tilda active IRC chatroom] you can join to ask for advice, or if you're really stuck you can email us on [mailto:badge@emfcamp.org badge@emfcamp.org].<br />
<br />
=How to update the badge software & program the badge=<br />
The badge software has been substantially updated since EMF, fixing bugs and removing features that will no longer work now you're away from our radio network. You should update your badge before starting to play with it any further. If you've never used an Arduino before this might be tricky - ask an Arduino-literate friend to help you, or drop by your nearest [http://hackspace.org.uk hackspace] and ask for advice.<br />
<br />
The badge is Arudino Due compatible, so [http://arduino.cc/en/Guide/ArduinoDue some of their instructions may help you if you have problems].<br />
<br />
==Set up your environment==<br />
* Plug your badge into your computer via a MicroUSB cable. Make sure the power switch on the back is set to "USB".<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* Download the TiLDA firmware code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE.<br />
* Now you have to change the sketchbook-folder to be the folder you just cloned or downloaded. To do this use File -> Preferences -> “Set Sketchbook location”. On MacOS, this is Arduino -> Preferences. <br />
* Restart the Arduino IDE.<br />
* Open sketch “EMF2014”.<br />
* Set Tools -> Board to MKe v0.333 (RTOS Core).<br />
* Set Tools -> Port to correct port for the Arduino<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Your badge should now be running the latest TiLDA firmware!<br />
<br />
==Programming the badge as an Arduino==<br />
The badge is completely Arduino Due compatible, simply upload normal Arduino code and the badge will function. However if you want to use any of the more complex hardware on the badge (such as the screen and radio) we recommend programming it using our FreeRTOS framework documented below.<br />
<br />
If you do program the badge with simple Arduino code but wish to switch back to our official firmware, simply change the sketch to "EMF2014" and upload again.<br />
<br />
To make the badge Arduino shield compatible, follow [https://wiki.emfcamp.org/wiki/TiLDA_MKe#Making_the_badge_Arduino_shield_compatible these instructions].<br />
<br />
==Programming the badge in FreeRTOS==<br />
===Your first “Hello world” app===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
===Why are things so different from standard Arduino code?===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spent quite a lot of time to make the built-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
==Debugging and Gotchas==<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
==Your own wireless badge network==<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
==Contribute==<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Using the badge hardware=<br />
The badge has a plethora of hardware built in for you to play with, everything from accelerometers and gyroscopes to hidden ethernet headers! Breaking it all down is too much detail for this document, however we'll call out some things we built in that you might want to play with.<br />
<br />
Remember the badge is Arduino Due compatible, and we broke out nearly all the features of the ARM chip so you can access them. [http://arduino.cc/en/Main/ArduinoBoardDue Anything the Due can do], the TiLDA can do!<br />
<br />
==Making the badge Arduino shield compatible==<br />
To make the badge Arduino shield compatible you'll need to solder simple strips of header pins (FIXME: Link to part) onto the back of the badge. This diagram (FIXME: DIAGRAM, LINK IT!) shows the placement.<br />
<br />
==Interesting things to play with==<br />
Most of the interesting things are on the back of the badge. They're clearly marked in white. [https://wiki.emfcamp.org/w/images/b/bd/Badge_Back.png This diagram of the back] should allow you to locate them.<br />
<br />
* Full Arduino shield compatible pins (Requires soldering the headers on the back of the badge)<br />
* Pins either side of the lanyard holes for conductive thread (D19, D18, GND, 3V3)<br />
* Infrared transmitter on the front (FIXME: Part number etc)<br />
* Piezo buzzer (FIXME: Pins and details)<br />
* On-board ethernet (not available on the Due) - requires breakout module (FIXME: Which one?)<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
* 128x64 pixel backlit LCD display (FIXME: Part number & spec sheet?)<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
* [http://shop.ciseco.co.uk/powerpod-1117-3v3/ PowerPOD] interface (FIXME: What does this do again?)<br />
* MicroSD adapter breakout (FIXME: Which component)<br />
* Compass (magnetometer) breakout (FIXME: Which component)<br />
* Reprogramming headers for the 868Mhz [http://www.ti.com/product/cc1110f32 CC1110 radio module]<br />
* 1 megabit flash module (FIXME: Part number etc)<br />
* SPI breakout<br />
* 2x RGB LEDs on the front<br />
<br />
FIXME: Anything else I missed? FTDI?<br />
<br />
==Included hardware==<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
=Useful Hacks!=<br />
==3d printable & laser-cuttable badge case==<br />
Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
==Convert images to TiLDA bitmap format==<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a fully working Piezo on board!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3810TiLDA MKe2014-11-28T20:14:17Z<p>Jonty: /* Hacking */</p>
<hr />
<div>[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
=EMF 2014 Badge= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards. We designed an Arduino compatible platform to allow easy reuse and access, and have published all code and design files.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==My badge is broken!==<br />
Due to the aforementioned supplier issues it is possible that you may have received a faulty badge, or it may have been damaged by connecting the battery backwards. If you badge will not turn on when it has been plugged in with a MicroUSB cable (and the power switch on the back is set to "USB"), or something else seems wrong with it, please email [mailto:badge@emfcamp.org badge@emfcamp.org] and we'll try to fix or replace your badge.<br />
<br />
==Basic post-event features==<br />
We made sure that the badge has a few features to play with once the event is over. More will be added over time as attendees submit changes to us.<br />
<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
But of course the point of the badge is to modify it and use it for other interesting things! The following sections describe how to update the firmware on the badge, how to use it as a simple arduino, and how to write your own code for the main badge firmware.<br />
<br />
==Getting help==<br />
The EMF 2014 badge is a complex piece of hardware and software, however remember that you can just treat it as an Arduino if you find it all too daunting.<br />
<br />
If you get stuck and need advice, there's an [http://webchat.freenode.net/?channels=tilda active IRC chatroom] you can join to ask for advice, or if you're really stuck you can email us on [mailto:badge@emfcamp.org badge@emfcamp.org].<br />
<br />
=How to update the badge software & program the badge=<br />
The badge software has been substantially updated since EMF, fixing bugs and removing features that will no longer work now you're away from our radio network. You should update your badge before starting to play with it any further. If you've never used an Arduino before this might be tricky - ask an Arduino-literate friend to help you, or drop by your nearest [http://hackspace.org.uk hackspace] and ask for advice.<br />
<br />
The badge is Arudino Due compatible, so [http://arduino.cc/en/Guide/ArduinoDue some of their instructions may help you if you have problems].<br />
<br />
==Set up your environment==<br />
* Plug your badge into your computer via a MicroUSB cable. Make sure the power switch on the back is set to "USB".<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* Download the TiLDA firmware code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE.<br />
* Now you have to change the sketchbook-folder to be the folder you just cloned or downloaded. To do this use File -> Preferences -> “Set Sketchbook location”. On MacOS, this is Arduino -> Preferences. <br />
* Restart the Arduino IDE.<br />
* Open sketch “EMF2014”.<br />
* Set Tools -> Board to MKe v0.333 (RTOS Core).<br />
* Set Tools -> Port to correct port for the Arduino<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Your badge should now be running the latest TiLDA firmware!<br />
<br />
==Programming the badge as an Arduino==<br />
The badge is completely Arduino Due compatible, simply upload normal Arduino code and the badge will function. However if you want to use any of the more complex hardware on the badge (such as the screen and radio) we recommend programming it using our FreeRTOS framework documented below.<br />
<br />
If you do program the badge with simple Arduino code but wish to switch back to our official firmware, simply change the sketch to "EMF2014" and upload again.<br />
<br />
To make the badge Arduino shield compatible, follow [https://wiki.emfcamp.org/wiki/TiLDA_MKe#Making_the_badge_Arduino_shield_compatible these instructions].<br />
<br />
==Programming the badge in FreeRTOS==<br />
===Your first “Hello world” app===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
===Why are things so different from standard Arduino code?===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spent quite a lot of time to make the built-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
==Debugging and Gotchas==<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
==Your own wireless badge network==<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
==Contribute==<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Using the badge hardware=<br />
The badge has a plethora of hardware built in for you to play with, everything from accelerometers and gyroscopes to hidden ethernet headers! Breaking it all down is too much detail for this document, however we'll call out some things we built in that you might want to play with.<br />
<br />
Remember the badge is Arduino Due compatible, and we broke out nearly all the features of the ARM chip so you can access them. [http://arduino.cc/en/Main/ArduinoBoardDue Anything the Due can do], the TiLDA can do!<br />
<br />
==Making the badge Arduino shield compatible==<br />
To make the badge Arduino shield compatible you'll need to solder simple strips of header pins (FIXME: Link to part) onto the back of the badge. This diagram (FIXME: DIAGRAM, LINK IT!) shows the placement.<br />
<br />
==Interesting things to play with==<br />
Most of the interesting things are on the back of the badge. They're clearly marked in white. [https://wiki.emfcamp.org/w/images/b/bd/Badge_Back.png This diagram of the back] should allow you to locate them.<br />
<br />
* Full Arduino shield compatible pins (Requires soldering the headers on the back of the badge)<br />
* Pins either side of the lanyard holes for conductive thread (D19, D18, GND, 3V3)<br />
* Infrared transmitter on the front (FIXME: Part number etc)<br />
* Piezo buzzer (FIXME: Pins and details)<br />
* On-board ethernet (not available on the Due) - requires breakout module (FIXME: Which one?)<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
* 128x64 pixel backlit LCD display (FIXME: Part number & spec sheet?)<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
* [http://shop.ciseco.co.uk/powerpod-1117-3v3/ PowerPOD] interface (FIXME: What does this do again?)<br />
* MicroSD adapter breakout (FIXME: Which component)<br />
* Compass (magnetometer) breakout (FIXME: Which component)<br />
* Reprogramming headers for the 868Mhz [http://www.ti.com/product/cc1110f32 CC1110 radio module]<br />
* 1 megabit flash module (FIXME: Part number etc)<br />
* SPI breakout<br />
* 2x RGB LEDs on the front<br />
<br />
FIXME: Anything else I missed? FTDI?<br />
<br />
==Included hardware==<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a fully working Piezo on board!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacks!=<br />
==3d printable & laser-cuttable badge case==<br />
Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
==Convert images to TiLDA bitmap format==<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3809TiLDA MKe2014-11-28T19:59:02Z<p>Jonty: /* Sound */</p>
<hr />
<div>[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
=EMF 2014 Badge= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards. We designed an Arduino compatible platform to allow easy reuse and access, and have published all code and design files.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==My badge is broken!==<br />
Due to the aforementioned supplier issues it is possible that you may have received a faulty badge, or it may have been damaged by connecting the battery backwards. If you badge will not turn on when it has been plugged in with a MicroUSB cable (and the power switch on the back is set to "USB"), or something else seems wrong with it, please email [mailto:badge@emfcamp.org badge@emfcamp.org] and we'll try to fix or replace your badge.<br />
<br />
==Basic post-event features==<br />
We made sure that the badge has a few features to play with once the event is over. More will be added over time as attendees submit changes to us.<br />
<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
But of course the point of the badge is to modify it and use it for other interesting things! The following sections describe how to update the firmware on the badge, how to use it as a simple arduino, and how to write your own code for the main badge firmware.<br />
<br />
==Getting help==<br />
The EMF 2014 badge is a complex piece of hardware and software, however remember that you can just treat it as an Arduino if you find it all too daunting.<br />
<br />
If you get stuck and need advice, there's an [http://webchat.freenode.net/?channels=tilda active IRC chatroom] you can join to ask for advice, or if you're really stuck you can email us on [mailto:badge@emfcamp.org badge@emfcamp.org].<br />
<br />
=How to update the badge software & program the badge=<br />
The badge software has been substantially updated since EMF, fixing bugs and removing features that will no longer work now you're away from our radio network. You should update your badge before starting to play with it any further. If you've never used an Arduino before this might be tricky - ask an Arduino-literate friend to help you, or drop by your nearest [http://hackspace.org.uk hackspace] and ask for advice.<br />
<br />
The badge is Arudino Due compatible, so [http://arduino.cc/en/Guide/ArduinoDue some of their instructions may help you if you have problems].<br />
<br />
==Set up your environment==<br />
* Plug your badge into your computer via a MicroUSB cable. Make sure the power switch on the back is set to "USB".<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* Download the TiLDA firmware code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE.<br />
* Now you have to change the sketchbook-folder to be the folder you just cloned or downloaded. To do this use File -> Preferences -> “Set Sketchbook location”. On MacOS, this is Arduino -> Preferences. <br />
* Restart the Arduino IDE.<br />
* Open sketch “EMF2014”.<br />
* Set Tools -> Board to MKe v0.333 (RTOS Core).<br />
* Set Tools -> Port to correct port for the Arduino<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Your badge should now be running the latest TiLDA firmware!<br />
<br />
==Programming the badge as an Arduino==<br />
The badge is completely Arduino Due compatible, simply upload normal Arduino code and the badge will function. However if you want to use any of the more complex hardware on the badge (such as the screen and radio) we recommend programming it using our FreeRTOS framework documented below.<br />
<br />
If you do program the badge with simple Arduino code but wish to switch back to our official firmware, simply change the sketch to "EMF2014" and upload again.<br />
<br />
To make the badge Arduino shield compatible, follow [https://wiki.emfcamp.org/wiki/TiLDA_MKe#Making_the_badge_Arduino_shield_compatible these instructions].<br />
<br />
==Programming the badge in FreeRTOS==<br />
===Your first “Hello world” app===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
===Why are things so different from standard Arduino code?===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spent quite a lot of time to make the built-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
==Debugging and Gotchas==<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
==Your own wireless badge network==<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
==Contribute==<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Using the badge hardware=<br />
The badge has a plethora of hardware built in for you to play with, everything from accelerometers and gyroscopes to hidden ethernet headers! Breaking it all down is too much detail for this document, however we'll call out some things we built in that you might want to play with.<br />
<br />
Remember the badge is Arduino Due compatible, and we broke out nearly all the features of the ARM chip so you can access them. [http://arduino.cc/en/Main/ArduinoBoardDue Anything the Due can do], the TiLDA can do!<br />
<br />
==Making the badge Arduino shield compatible==<br />
To make the badge Arduino shield compatible you'll need to solder simple strips of header pins (FIXME: Link to part) onto the back of the badge. This diagram (FIXME: DIAGRAM, LINK IT!) shows the placement.<br />
<br />
==Interesting things to play with==<br />
Most of the interesting things are on the back of the badge. They're clearly marked in white. [https://wiki.emfcamp.org/w/images/b/bd/Badge_Back.png This diagram of the back] should allow you to locate them.<br />
<br />
* Full Arduino shield compatible pins (Requires soldering the headers on the back of the badge)<br />
* Pins either side of the lanyard holes for conductive thread (D19, D18, GND, 3V3)<br />
* Infrared transmitter on the front (FIXME: Part number etc)<br />
* Piezo buzzer (FIXME: Pins and details)<br />
* On-board ethernet (not available on the Due) - requires breakout module (FIXME: Which one?)<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
* 128x64 pixel backlit LCD display (FIXME: Part number & spec sheet?)<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
* [http://shop.ciseco.co.uk/powerpod-1117-3v3/ PowerPOD] interface (FIXME: What does this do again?)<br />
* MicroSD adapter breakout (FIXME: Which component)<br />
* Compass (magnetometer) breakout (FIXME: Which component)<br />
* Reprogramming headers for the 868Mhz [http://www.ti.com/product/cc1110f32 CC1110 radio module]<br />
* 1 megabit flash module (FIXME: Part number etc)<br />
* SPI breakout<br />
* 2x RGB LEDs on the front<br />
<br />
FIXME: Anything else I missed? FTDI?<br />
<br />
==Included hardware==<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a fully working Piezo on board!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe_Competition&diff=3808TiLDA MKe Competition2014-11-28T19:58:24Z<p>Jonty: </p>
<hr />
<div>Now that EMF is over and you've returned home, its time to dig out your EMF badge and start playing!<br />
<br />
We'll be rewarding the best hack using the badge with '''two tickets to EMF 2016''', and '''two tickets to the one-day event in 2015'''. We'll also have '''other prizes available''' for hacks in different categories!<br />
<br />
==Submitting your hack==<br />
Email [mailto:competition@emfcamp.org competition@emfcamp.org] with the details of your hack, either linking to an existing website or attaching documentation to the email.<br />
<br />
'''Submissions close on the 31st March 2015 at midnight''', with the '''winners being announced on April 15th'''.<br />
<br />
==Judging==<br />
The entries will be judged by the same team that designed and built the badges. They'll be looking for cool software that other badge owners can use, unexpected uses of the hardware, and generally delightful hacks. Don't be scared if this is new to you, the judges will take experience into account!<br />
<br />
We'll also have '''prizes for the runners up''', and for people who are new to hacking.<br />
<br />
==Wait, how do I modify and use the badge?==<br />
We've got comprehensive documentation over on the [https://wiki.emfcamp.org/wiki/TiLDA_MKe badge page].<br />
<br />
==My badge is broken so I can't enter!==<br />
If your badge was one of the few that suffered a hardware failure, [mailto:badge@emfcamp.org get in touch] and we'll be happy to replace it so you can take part in the competition.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe_Competition&diff=3807TiLDA MKe Competition2014-11-28T19:57:16Z<p>Jonty: </p>
<hr />
<div>Now that EMF is over and you've returned home, its time to dig out your EMF badge and start playing!<br />
<br />
We'll be rewarding the best hack using the badge with '''two tickets to EMF 2016''', and '''two tickets to the one-day event in 2015'''. We might also have '''other prizes available''' for hacks in different categories!<br />
<br />
==Submitting your hack==<br />
Email [mailto:competition@emfcamp.org competition@emfcamp.org] with the details of your hack, either linking to an existing website or attaching documentation to the email.<br />
<br />
'''Submissions close on the 31st March 2015 at midnight''', with the winners being announced on April 15th.<br />
<br />
==Judging==<br />
The entries will be judged by the same team that designed and built the badges. They'll be looking for cool software that other badge owners can use, unexpected uses of the hardware, and generally delightful hacks. Don't be scared if this is new to you, the judges will take experience into account!<br />
<br />
We'll also have prizes for the runners up, and for people who are new to hacking.<br />
<br />
==Wait, how do I modify and use the badge?==<br />
We've got comprehensive documentation over on the [https://wiki.emfcamp.org/wiki/TiLDA_MKe badge page].<br />
<br />
==My badge is broken so I can't enter!==<br />
If your badge was one of the few that suffered a hardware failure, [mailto:badge@emfcamp.org get in touch] and we'll be happy to replace it so you can take part in the competition.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3806TiLDA MKe2014-11-28T19:36:06Z<p>Jonty: /* Programming the badge as an Arduino */</p>
<hr />
<div>[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
=EMF 2014 Badge= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards. We designed an Arduino compatible platform to allow easy reuse and access, and have published all code and design files.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==My badge is broken!==<br />
Due to the aforementioned supplier issues it is possible that you may have received a faulty badge, or it may have been damaged by connecting the battery backwards. If you badge will not turn on when it has been plugged in with a MicroUSB cable (and the power switch on the back is set to "USB"), or something else seems wrong with it, please email [mailto:badge@emfcamp.org badge@emfcamp.org] and we'll try to fix or replace your badge.<br />
<br />
==Basic post-event features==<br />
We made sure that the badge has a few features to play with once the event is over. More will be added over time as attendees submit changes to us.<br />
<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
But of course the point of the badge is to modify it and use it for other interesting things! The following sections describe how to update the firmware on the badge, how to use it as a simple arduino, and how to write your own code for the main badge firmware.<br />
<br />
==Getting help==<br />
The EMF 2014 badge is a complex piece of hardware and software, however remember that you can just treat it as an Arduino if you find it all too daunting.<br />
<br />
If you get stuck and need advice, there's an [http://webchat.freenode.net/?channels=tilda active IRC chatroom] you can join to ask for advice, or if you're really stuck you can email us on [mailto:badge@emfcamp.org badge@emfcamp.org].<br />
<br />
=How to update the badge software & program the badge=<br />
The badge software has been substantially updated since EMF, fixing bugs and removing features that will no longer work now you're away from our radio network. You should update your badge before starting to play with it any further. If you've never used an Arduino before this might be tricky - ask an Arduino-literate friend to help you, or drop by your nearest [http://hackspace.org.uk hackspace] and ask for advice.<br />
<br />
The badge is Arudino Due compatible, so [http://arduino.cc/en/Guide/ArduinoDue some of their instructions may help you if you have problems].<br />
<br />
==Set up your environment==<br />
* Plug your badge into your computer via a MicroUSB cable. Make sure the power switch on the back is set to "USB".<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* Download the TiLDA firmware code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE.<br />
* Now you have to change the sketchbook-folder to be the folder you just cloned or downloaded. To do this use File -> Preferences -> “Set Sketchbook location”. On MacOS, this is Arduino -> Preferences. <br />
* Restart the Arduino IDE.<br />
* Open sketch “EMF2014”.<br />
* Set Tools -> Board to MKe v0.333 (RTOS Core).<br />
* Set Tools -> Port to correct port for the Arduino<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Your badge should now be running the latest TiLDA firmware!<br />
<br />
==Programming the badge as an Arduino==<br />
The badge is completely Arduino Due compatible, simply upload normal Arduino code and the badge will function. However if you want to use any of the more complex hardware on the badge (such as the screen and radio) we recommend programming it using our FreeRTOS framework documented below.<br />
<br />
If you do program the badge with simple Arduino code but wish to switch back to our official firmware, simply change the sketch to "EMF2014" and upload again.<br />
<br />
To make the badge Arduino shield compatible, follow [https://wiki.emfcamp.org/wiki/TiLDA_MKe#Making_the_badge_Arduino_shield_compatible these instructions].<br />
<br />
==Programming the badge in FreeRTOS==<br />
===Your first “Hello world” app===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
===Why are things so different from standard Arduino code?===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spent quite a lot of time to make the built-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
==Debugging and Gotchas==<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
==Your own wireless badge network==<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
==Contribute==<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Using the badge hardware=<br />
The badge has a plethora of hardware built in for you to play with, everything from accelerometers and gyroscopes to hidden ethernet headers! Breaking it all down is too much detail for this document, however we'll call out some things we built in that you might want to play with.<br />
<br />
Remember the badge is Arduino Due compatible, and we broke out nearly all the features of the ARM chip so you can access them. [http://arduino.cc/en/Main/ArduinoBoardDue Anything the Due can do], the TiLDA can do!<br />
<br />
==Making the badge Arduino shield compatible==<br />
To make the badge Arduino shield compatible you'll need to solder simple strips of header pins (FIXME: Link to part) onto the back of the badge. This diagram (FIXME: DIAGRAM, LINK IT!) shows the placement.<br />
<br />
==Interesting things to play with==<br />
Most of the interesting things are on the back of the badge. They're clearly marked in white. [https://wiki.emfcamp.org/w/images/b/bd/Badge_Back.png This diagram of the back] should allow you to locate them.<br />
<br />
* Full Arduino shield compatible pins (Requires soldering the headers on the back of the badge)<br />
* Pins either side of the lanyard holes for conductive thread (D19, D18, GND, 3V3)<br />
* Infrared transmitter on the front (FIXME: Part number etc)<br />
* Piezo buzzer (FIXME: Pins and details)<br />
* On-board ethernet (not available on the Due) - requires breakout module (FIXME: Which one?)<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
* 128x64 pixel backlit LCD display (FIXME: Part number & spec sheet?)<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
* [http://shop.ciseco.co.uk/powerpod-1117-3v3/ PowerPOD] interface (FIXME: What does this do again?)<br />
* MicroSD adapter breakout (FIXME: Which component)<br />
* Compass (magnetometer) breakout (FIXME: Which component)<br />
* Reprogramming headers for the 868Mhz [http://www.ti.com/product/cc1110f32 CC1110 radio module]<br />
* 1 megabit flash module (FIXME: Part number etc)<br />
* SPI breakout<br />
* 2x RGB LEDs on the front<br />
<br />
FIXME: Anything else I missed? FTDI?<br />
<br />
==Included hardware==<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3805TiLDA MKe2014-11-28T19:35:12Z<p>Jonty: /* Using the badge hardware */</p>
<hr />
<div>[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
=EMF 2014 Badge= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards. We designed an Arduino compatible platform to allow easy reuse and access, and have published all code and design files.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==My badge is broken!==<br />
Due to the aforementioned supplier issues it is possible that you may have received a faulty badge, or it may have been damaged by connecting the battery backwards. If you badge will not turn on when it has been plugged in with a MicroUSB cable (and the power switch on the back is set to "USB"), or something else seems wrong with it, please email [mailto:badge@emfcamp.org badge@emfcamp.org] and we'll try to fix or replace your badge.<br />
<br />
==Basic post-event features==<br />
We made sure that the badge has a few features to play with once the event is over. More will be added over time as attendees submit changes to us.<br />
<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
But of course the point of the badge is to modify it and use it for other interesting things! The following sections describe how to update the firmware on the badge, how to use it as a simple arduino, and how to write your own code for the main badge firmware.<br />
<br />
==Getting help==<br />
The EMF 2014 badge is a complex piece of hardware and software, however remember that you can just treat it as an Arduino if you find it all too daunting.<br />
<br />
If you get stuck and need advice, there's an [http://webchat.freenode.net/?channels=tilda active IRC chatroom] you can join to ask for advice, or if you're really stuck you can email us on [mailto:badge@emfcamp.org badge@emfcamp.org].<br />
<br />
=How to update the badge software & program the badge=<br />
The badge software has been substantially updated since EMF, fixing bugs and removing features that will no longer work now you're away from our radio network. You should update your badge before starting to play with it any further. If you've never used an Arduino before this might be tricky - ask an Arduino-literate friend to help you, or drop by your nearest [http://hackspace.org.uk hackspace] and ask for advice.<br />
<br />
The badge is Arudino Due compatible, so [http://arduino.cc/en/Guide/ArduinoDue some of their instructions may help you if you have problems].<br />
<br />
==Set up your environment==<br />
* Plug your badge into your computer via a MicroUSB cable. Make sure the power switch on the back is set to "USB".<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* Download the TiLDA firmware code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE.<br />
* Now you have to change the sketchbook-folder to be the folder you just cloned or downloaded. To do this use File -> Preferences -> “Set Sketchbook location”. On MacOS, this is Arduino -> Preferences. <br />
* Restart the Arduino IDE.<br />
* Open sketch “EMF2014”.<br />
* Set Tools -> Board to MKe v0.333 (RTOS Core).<br />
* Set Tools -> Port to correct port for the Arduino<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Your badge should now be running the latest TiLDA firmware!<br />
<br />
==Programming the badge as an Arduino==<br />
The badge is completely Arduino Due compatible, simply upload normal Arduino code and the badge will function. However if you want to use any of the more complex hardware on the badge (such as the screen and radio) we recommend programming it using our FreeRTOS framework documented below.<br />
<br />
If you do program the badge with simple Arduino code but wish to switch back to our official firmware, simply change the sketch to "EMF2014" and upload again.<br />
<br />
==Programming the badge in FreeRTOS==<br />
===Your first “Hello world” app===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
===Why are things so different from standard Arduino code?===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spent quite a lot of time to make the built-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
==Debugging and Gotchas==<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
==Your own wireless badge network==<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
==Contribute==<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Using the badge hardware=<br />
The badge has a plethora of hardware built in for you to play with, everything from accelerometers and gyroscopes to hidden ethernet headers! Breaking it all down is too much detail for this document, however we'll call out some things we built in that you might want to play with.<br />
<br />
Remember the badge is Arduino Due compatible, and we broke out nearly all the features of the ARM chip so you can access them. [http://arduino.cc/en/Main/ArduinoBoardDue Anything the Due can do], the TiLDA can do!<br />
<br />
==Making the badge Arduino shield compatible==<br />
To make the badge Arduino shield compatible you'll need to solder simple strips of header pins (FIXME: Link to part) onto the back of the badge. This diagram (FIXME: DIAGRAM, LINK IT!) shows the placement.<br />
<br />
==Interesting things to play with==<br />
Most of the interesting things are on the back of the badge. They're clearly marked in white. [https://wiki.emfcamp.org/w/images/b/bd/Badge_Back.png This diagram of the back] should allow you to locate them.<br />
<br />
* Full Arduino shield compatible pins (Requires soldering the headers on the back of the badge)<br />
* Pins either side of the lanyard holes for conductive thread (D19, D18, GND, 3V3)<br />
* Infrared transmitter on the front (FIXME: Part number etc)<br />
* Piezo buzzer (FIXME: Pins and details)<br />
* On-board ethernet (not available on the Due) - requires breakout module (FIXME: Which one?)<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
* 128x64 pixel backlit LCD display (FIXME: Part number & spec sheet?)<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
* [http://shop.ciseco.co.uk/powerpod-1117-3v3/ PowerPOD] interface (FIXME: What does this do again?)<br />
* MicroSD adapter breakout (FIXME: Which component)<br />
* Compass (magnetometer) breakout (FIXME: Which component)<br />
* Reprogramming headers for the 868Mhz [http://www.ti.com/product/cc1110f32 CC1110 radio module]<br />
* 1 megabit flash module (FIXME: Part number etc)<br />
* SPI breakout<br />
* 2x RGB LEDs on the front<br />
<br />
FIXME: Anything else I missed? FTDI?<br />
<br />
==Included hardware==<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3804TiLDA MKe2014-11-28T19:33:09Z<p>Jonty: /* Using the badge hardware */</p>
<hr />
<div>[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
=EMF 2014 Badge= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards. We designed an Arduino compatible platform to allow easy reuse and access, and have published all code and design files.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==My badge is broken!==<br />
Due to the aforementioned supplier issues it is possible that you may have received a faulty badge, or it may have been damaged by connecting the battery backwards. If you badge will not turn on when it has been plugged in with a MicroUSB cable (and the power switch on the back is set to "USB"), or something else seems wrong with it, please email [mailto:badge@emfcamp.org badge@emfcamp.org] and we'll try to fix or replace your badge.<br />
<br />
==Basic post-event features==<br />
We made sure that the badge has a few features to play with once the event is over. More will be added over time as attendees submit changes to us.<br />
<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
But of course the point of the badge is to modify it and use it for other interesting things! The following sections describe how to update the firmware on the badge, how to use it as a simple arduino, and how to write your own code for the main badge firmware.<br />
<br />
==Getting help==<br />
The EMF 2014 badge is a complex piece of hardware and software, however remember that you can just treat it as an Arduino if you find it all too daunting.<br />
<br />
If you get stuck and need advice, there's an [http://webchat.freenode.net/?channels=tilda active IRC chatroom] you can join to ask for advice, or if you're really stuck you can email us on [mailto:badge@emfcamp.org badge@emfcamp.org].<br />
<br />
=How to update the badge software & program the badge=<br />
The badge software has been substantially updated since EMF, fixing bugs and removing features that will no longer work now you're away from our radio network. You should update your badge before starting to play with it any further. If you've never used an Arduino before this might be tricky - ask an Arduino-literate friend to help you, or drop by your nearest [http://hackspace.org.uk hackspace] and ask for advice.<br />
<br />
The badge is Arudino Due compatible, so [http://arduino.cc/en/Guide/ArduinoDue some of their instructions may help you if you have problems].<br />
<br />
==Set up your environment==<br />
* Plug your badge into your computer via a MicroUSB cable. Make sure the power switch on the back is set to "USB".<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* Download the TiLDA firmware code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE.<br />
* Now you have to change the sketchbook-folder to be the folder you just cloned or downloaded. To do this use File -> Preferences -> “Set Sketchbook location”. On MacOS, this is Arduino -> Preferences. <br />
* Restart the Arduino IDE.<br />
* Open sketch “EMF2014”.<br />
* Set Tools -> Board to MKe v0.333 (RTOS Core).<br />
* Set Tools -> Port to correct port for the Arduino<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Your badge should now be running the latest TiLDA firmware!<br />
<br />
==Programming the badge as an Arduino==<br />
The badge is completely Arduino Due compatible, simply upload normal Arduino code and the badge will function. However if you want to use any of the more complex hardware on the badge (such as the screen and radio) we recommend programming it using our FreeRTOS framework documented below.<br />
<br />
If you do program the badge with simple Arduino code but wish to switch back to our official firmware, simply change the sketch to "EMF2014" and upload again.<br />
<br />
==Programming the badge in FreeRTOS==<br />
===Your first “Hello world” app===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
===Why are things so different from standard Arduino code?===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spent quite a lot of time to make the built-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
==Debugging and Gotchas==<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
==Your own wireless badge network==<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
==Contribute==<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Using the badge hardware=<br />
To make the badge Arduino shield compatible you'll need to solder simple strips of header pins (FIXME: Link to part) onto the back of the badge. This diagram (FIXME: DIAGRAM, LINK IT!) shows the placement.<br />
<br />
The badge has a plethora of hardware built in for you to play with, everything from accelerometers and gyroscopes to hidden ethernet headers! Breaking it all down is too much detail for this document, however we'll call out some things we built in that you might want to play with.<br />
<br />
Remember the badge is Arduino Due compatible, and we broke out nearly all the features of the ARM chip so you can access them. [http://arduino.cc/en/Main/ArduinoBoardDue Anything the Due can do], the TiLDA can do!<br />
<br />
==Interesting things to play with==<br />
Most of the interesting things are on the back of the badge. They're clearly marked in white. [https://wiki.emfcamp.org/w/images/b/bd/Badge_Back.png This diagram of the back] should allow you to locate them.<br />
<br />
* Full Arduino shield compatible pins (Requires soldering the headers on the back of the badge)<br />
* Pins either side of the lanyard holes for conductive thread (D19, D18, GND, 3V3)<br />
* Infrared transmitter on the front (FIXME: Part number etc)<br />
* Piezo buzzer (FIXME: Pins and details)<br />
* On-board ethernet (not available on the Due) - requires breakout module (FIXME: Which one?)<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
* 128x64 pixel backlit LCD display (FIXME: Part number & spec sheet?)<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
* [http://shop.ciseco.co.uk/powerpod-1117-3v3/ PowerPOD] interface (FIXME: What does this do again?)<br />
* MicroSD adapter breakout (FIXME: Which component)<br />
* Compass (magnetometer) breakout (FIXME: Which component)<br />
* Reprogramming headers for the 868Mhz [http://www.ti.com/product/cc1110f32 CC1110 radio module]<br />
* 1 megabit flash module (FIXME: Part number etc)<br />
* SPI breakout<br />
* 2x RGB LEDs on the front<br />
<br />
FIXME: Anything else I missed? FTDI?<br />
<br />
==Included hardware==<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3803TiLDA MKe2014-11-28T19:13:57Z<p>Jonty: </p>
<hr />
<div>[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
=EMF 2014 Badge= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards. We designed an Arduino compatible platform to allow easy reuse and access, and have published all code and design files.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==My badge is broken!==<br />
Due to the aforementioned supplier issues it is possible that you may have received a faulty badge, or it may have been damaged by connecting the battery backwards. If you badge will not turn on when it has been plugged in with a MicroUSB cable (and the power switch on the back is set to "USB"), or something else seems wrong with it, please email [mailto:badge@emfcamp.org badge@emfcamp.org] and we'll try to fix or replace your badge.<br />
<br />
==Basic post-event features==<br />
We made sure that the badge has a few features to play with once the event is over. More will be added over time as attendees submit changes to us.<br />
<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
But of course the point of the badge is to modify it and use it for other interesting things! The following sections describe how to update the firmware on the badge, how to use it as a simple arduino, and how to write your own code for the main badge firmware.<br />
<br />
==Getting help==<br />
The EMF 2014 badge is a complex piece of hardware and software, however remember that you can just treat it as an Arduino if you find it all too daunting.<br />
<br />
If you get stuck and need advice, there's an [http://webchat.freenode.net/?channels=tilda active IRC chatroom] you can join to ask for advice, or if you're really stuck you can email us on [mailto:badge@emfcamp.org badge@emfcamp.org].<br />
<br />
=How to update the badge software & program the badge=<br />
The badge software has been substantially updated since EMF, fixing bugs and removing features that will no longer work now you're away from our radio network. You should update your badge before starting to play with it any further. If you've never used an Arduino before this might be tricky - ask an Arduino-literate friend to help you, or drop by your nearest [http://hackspace.org.uk hackspace] and ask for advice.<br />
<br />
The badge is Arudino Due compatible, so [http://arduino.cc/en/Guide/ArduinoDue some of their instructions may help you if you have problems].<br />
<br />
==Set up your environment==<br />
* Plug your badge into your computer via a MicroUSB cable. Make sure the power switch on the back is set to "USB".<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* Download the TiLDA firmware code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE.<br />
* Now you have to change the sketchbook-folder to be the folder you just cloned or downloaded. To do this use File -> Preferences -> “Set Sketchbook location”. On MacOS, this is Arduino -> Preferences. <br />
* Restart the Arduino IDE.<br />
* Open sketch “EMF2014”.<br />
* Set Tools -> Board to MKe v0.333 (RTOS Core).<br />
* Set Tools -> Port to correct port for the Arduino<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Your badge should now be running the latest TiLDA firmware!<br />
<br />
==Programming the badge as an Arduino==<br />
The badge is completely Arduino Due compatible, simply upload normal Arduino code and the badge will function. However if you want to use any of the more complex hardware on the badge (such as the screen and radio) we recommend programming it using our FreeRTOS framework documented below.<br />
<br />
If you do program the badge with simple Arduino code but wish to switch back to our official firmware, simply change the sketch to "EMF2014" and upload again.<br />
<br />
==Programming the badge in FreeRTOS==<br />
===Your first “Hello world” app===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
===Why are things so different from standard Arduino code?===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spent quite a lot of time to make the built-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
==Debugging and Gotchas==<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
==Your own wireless badge network==<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
==Contribute==<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Using the badge hardware=<br />
The badge has a plethora of hardware built in for you to play with, everything from accelerometers and gyroscopes to hidden ethernet headers! Breaking it all down is too much detail for this document, however we'll call out some things we built in that you might want to play with.<br />
<br />
Remember the badge is Arduino Due compatible, and we broke out nearly all the features of the ARM chip so you can access them. [http://arduino.cc/en/Main/ArduinoBoardDue Anything the Due can do], the TiLDA can do!<br />
<br />
==Interesting things to play with==<br />
Most of the interesting things are on the back of the badge. They're clearly marked in white. [https://wiki.emfcamp.org/w/images/b/bd/Badge_Back.png This diagram of the back] should allow you to locate them.<br />
<br />
* Full Arduino shield compatible pins (Requires soldering the headers on the back of the badge)<br />
* Pins either side of the lanyard holes for conductive thread (D19, D18, GND, 3V3)<br />
* Infrared transmitter on the front (FIXME: Part number etc)<br />
* Piezo buzzer (FIXME: Pins and details)<br />
* On-board ethernet (not available on the Due) - requires breakout module (FIXME: Which one?)<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
* 128x64 pixel backlit LCD display (FIXME: Part number & spec sheet?)<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
* [http://shop.ciseco.co.uk/powerpod-1117-3v3/ PowerPOD] interface (FIXME: What does this do again?)<br />
* MicroSD adapter breakout (FIXME: Which component)<br />
* Compass (magnetometer) breakout (FIXME: Which component)<br />
* Reprogramming headers for the 868Mhz [http://www.ti.com/product/cc1110f32 CC1110 radio module]<br />
* 1 megabit flash module (FIXME: Part number etc)<br />
* SPI breakout<br />
* 2x RGB LEDs on the front<br />
<br />
FIXME: Anything else I missed? FTDI?<br />
<br />
==Included hardware==<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3802TiLDA MKe2014-11-28T18:36:42Z<p>Jonty: </p>
<hr />
<div>[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
=EMF 2014 Badge= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards. We designed an Arduino compatible platform to allow easy reuse and access, and have published all code and design files.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==My badge is broken!==<br />
Due to the aforementioned supplier issues it is possible that you may have received a faulty badge, or it may have been damaged by connecting the battery backwards. If you badge will not turn on when it has been plugged in with a MicroUSB cable (and the power switch on the back is set to "USB"), or something else seems wrong with it, please email [mailto:badge@emfcamp.org badge@emfcamp.org] and we'll try to fix or replace your badge.<br />
<br />
==Basic post-event features==<br />
We made sure that the badge has a few features to play with once the event is over. More will be added over time as attendees submit changes to us.<br />
<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
But of course the point of the badge is to modify it and use it for other interesting things! The following sections describe how to update the firmware on the badge, how to use it as a simple arduino, and how to write your own code for the main badge firmware.<br />
<br />
==Getting help==<br />
The EMF 2014 badge is a complex piece of hardware and software, however remember that you can just treat it as an Arduino if you find it all too daunting.<br />
<br />
If you get stuck and need advice, there's an [http://webchat.freenode.net/?channels=tilda active IRC chatroom] you can join to ask for advice, or if you're really stuck you can email us on [mailto:badge@emfcamp.org badge@emfcamp.org].<br />
<br />
=How to update the badge software & program the badge=<br />
The badge software has been substantially updated since EMF, fixing bugs and removing features that will no longer work now you're away from our radio network. You should update your badge before starting to play with it any further. If you've never used an Arduino before this might be tricky - ask an Arduino-literate friend to help you, or drop by your nearest [http://hackspace.org.uk hackspace] and ask for advice.<br />
<br />
==Set up your environment==<br />
* Plug your badge into your computer via a MicroUSB cable. Make sure the power switch on the back is set to "USB".<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* Download the TiLDA firmware code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE.<br />
* Now you have to change the sketchbook-folder to be the folder you just cloned or downloaded. To do this use File -> Preferences -> “Set Sketchbook location”. On MacOS, this is Arduino -> Preferences. <br />
* Restart the Arduino IDE.<br />
* Open sketch “EMF2014”.<br />
* Set Tools -> Board to MKe v0.333 (RTOS Core).<br />
* Set Tools -> Port to correct port for the Arduino<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Your badge should now be running the latest TiLDA firmware!<br />
<br />
==Programming the badge as an Arduino==<br />
The badge is completely Arduino Due compatible, simply upload normal Arduino code and the badge will function. However if you want to use any of the more complex hardware on the badge (such as the screen and radio) we recommend programming it using our FreeRTOS framework documented below.<br />
<br />
If you do program the badge with simple Arduino code but wish to switch back to our official firmware, simply change the sketch to "EMF2014" and upload again.<br />
<br />
==Programming the badge in FreeRTOS==<br />
===Your first “Hello world” app===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
===Why are things so different from standard Arduino code?===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spent quite a lot of time to make the built-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
==Debugging and Gotchas==<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
==Your own wireless badge network==<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
==Contribute==<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Hardware=<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3801TiLDA MKe2014-11-28T18:29:11Z<p>Jonty: </p>
<hr />
<div>[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
=EMF 2014 Badge= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards. We designed an Arduino compatible platform to allow easy reuse and access, and have published all code and design files.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==My badge is broken!==<br />
Due to the aforementioned supplier issues it is possible that you may have received a faulty badge, or it may have been damaged by connecting the battery backwards. If you badge will not turn on when it has been plugged in with a MicroUSB cable (and the power switch on the back is set to "USB"), or something else seems wrong with it, please email [mailto:badge@emfcamp.org badge@emfcamp.org] and we'll try to fix or replace your badge.<br />
<br />
==Basic post-event features==<br />
We made sure that the badge has a few features to play with once the event is over. More will be added over time as attendees submit changes to us.<br />
<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
But of course the point of the badge is to modify it and use it for other interesting things! The following sections describe how to update the firmware on the badge, how to use it as a simple arduino, and how to write your own code for the main badge firmware.<br />
<br />
=How to update the badge software & program the badge=<br />
The badge software has been substantially updated since EMF, fixing bugs and removing features that will no longer work now you're away from our radio network. You should update your badge before starting to play with it any further. If you've never used an Arduino before this might be tricky - ask an Arduino-literate friend to help you, or drop by your nearest [http://hackspace.org.uk hackspace] and ask for advice.<br />
<br />
==Set up your environment==<br />
* Plug your badge into your computer via a MicroUSB cable. Make sure the power switch on the back is set to "USB".<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* Download the TiLDA firmware code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE.<br />
* Now you have to change the sketchbook-folder to be the folder you just cloned or downloaded. To do this use File -> Preferences -> “Set Sketchbook location”. On MacOS, this is Arduino -> Preferences. <br />
* Restart the Arduino IDE.<br />
* Open sketch “EMF2014”.<br />
* Set Tools -> Board to MKe v0.333 (RTOS Core).<br />
* Set Tools -> Port to correct port for the Arduino<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Your badge should now be running the latest TiLDA firmware!<br />
<br />
==Programming the badge as an Arduino==<br />
The badge is completely Arduino Due compatible, simply upload normal Arduino code and the badge will function. However if you want to use any of the more complex hardware on the badge (such as the screen and radio) we recommend programming it using our FreeRTOS framework documented below.<br />
<br />
If you do program the badge with simple Arduino code but wish to switch back to our official firmware, simply change the sketch to "EMF2014" and upload again.<br />
<br />
==Programming the badge in FreeRTOS==<br />
===Your first “Hello world” app===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
===Why are things so different from standard Arduino code?===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spent quite a lot of time to make the built-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
==Debugging and Gotchas==<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
==Your own wireless badge network==<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
==Contribute==<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Hardware=<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3800TiLDA MKe2014-11-28T18:06:49Z<p>Jonty: </p>
<hr />
<div>[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
=EMF 2014 Badge= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards. We designed an Arduino compatible platform to allow easy reuse and access, and have published all code and design files.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==My badge is broken!==<br />
Due to the aforementioned supplier issues it is possible that you may have received a faulty badge, or it may have been damaged by connecting the battery backwards. If you badge will not turn on when it has been plugged in with a MicroUSB cable (and the power switch on the back is set to "USB"), or something else seems wrong with it, please email [mailto:badge@emfcamp.org badge@emfcamp.org] and we'll try to fix or replace your badge.<br />
<br />
==Basic features and functions==<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
== How to get going ==<br />
=== Set up your environment ===<br />
* Plug your badge into your computer via USB<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* “git clone” or download TiLDA source code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE. <br />
* Now you have to change the sketchbook-folder to be the folder you just cloned. To do this use File | Preferences | “Set Sketchbook location”. On MacOS, this is Arduino | Preferences <br />
* Restart the Arduino IDE<br />
* Open sketch “EMF2014”<br />
* Set Tools | Board to MKe v0.333 (RTOS Core)<br />
* Set Tools | Port to correct port (you might have to research this - some operating systems like Windows require you to install drivers or become a member of a certain group)<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Woohoo - You just successfully uploaded code to your badge<br />
<br />
=== Your first “Hello world” app ===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
=== Why are things so different from standard Arduino code? ===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spend quite a lot of time to make the build-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== How to use the badge with pure Arduino code ===<br />
If you prefer you can always start from scratch without FreeRTOS or any of our code, just keep in mind that you won’t be able to receive messages via radio or use any of the API features we already added. Just start a new sketch in the Arduino IDE for that and get going. If you want to load the main firmware again just change the sketch to “EMF2014” and upload again.<br />
<br />
=== Debugging and Gotchas ===<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
=== Radio infrastructure ===<br />
The radio infrastructure is distributed between DKs. Every “gateway” has a Raspberry Pi with two Ciseco USB radios. We never had the chance to actually try it with a large number of badges in the same spot, so please don’t expect it to work perfectly.<br />
<br />
=== Your own wireless badge network ===<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
=== Contribute ===<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Hardware=<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3799TiLDA MKe2014-11-28T18:04:48Z<p>Jonty: </p>
<hr />
<div>[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
=Aim= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards, we designed an Arduino compatible platform to allow easy reuse and access. As with the previous badge all code and design files are available.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==My badge is broken!==<br />
Due to the aforementioned supplier issues it is possible that you may have received a faulty badge, or it may have been damaged by connecting the battery backwards. If you badge will not turn on when it has been plugged in with a MicroUSB cable (and the power switch on the back is set to "USB"), or something else seems wrong with it, please email [mailto:badge@emfcamp.org badge@emfcamp.org] and we'll try to fix or replace your badge.<br />
<br />
==Basic features and functions==<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
== How to get going ==<br />
=== Set up your environment ===<br />
* Plug your badge into your computer via USB<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* “git clone” or download TiLDA source code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE. <br />
* Now you have to change the sketchbook-folder to be the folder you just cloned. To do this use File | Preferences | “Set Sketchbook location”. On MacOS, this is Arduino | Preferences <br />
* Restart the Arduino IDE<br />
* Open sketch “EMF2014”<br />
* Set Tools | Board to MKe v0.333 (RTOS Core)<br />
* Set Tools | Port to correct port (you might have to research this - some operating systems like Windows require you to install drivers or become a member of a certain group)<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Woohoo - You just successfully uploaded code to your badge<br />
<br />
=== Your first “Hello world” app ===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
=== Why are things so different from standard Arduino code? ===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spend quite a lot of time to make the build-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== How to use the badge with pure Arduino code ===<br />
If you prefer you can always start from scratch without FreeRTOS or any of our code, just keep in mind that you won’t be able to receive messages via radio or use any of the API features we already added. Just start a new sketch in the Arduino IDE for that and get going. If you want to load the main firmware again just change the sketch to “EMF2014” and upload again.<br />
<br />
=== Debugging and Gotchas ===<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
=== Radio infrastructure ===<br />
The radio infrastructure is distributed between DKs. Every “gateway” has a Raspberry Pi with two Ciseco USB radios. We never had the chance to actually try it with a large number of badges in the same spot, so please don’t expect it to work perfectly.<br />
<br />
=== Your own wireless badge network ===<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
=== Contribute ===<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Hardware=<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3798TiLDA MKe2014-11-28T17:58:31Z<p>Jonty: </p>
<hr />
<div>The TiLDA MKe project, Code name "ElectroMagnetic Boogaloo", is being headed by [[User:Dpslwk|'RepRap' Matt]] and [[User:thinkl33t|Bob]]<br />
[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
Please Note: There are a couple of minor hardware and some firmware issues that might be affecting your badge. If you've let the magic smoke out of your charge controller or have tried to re-flash and ended up with nothing but a couple of dimly glowing lights then DO NOT DESPAIR -It's recoverable and fixes, documentation and lots of firmware are still being produced :)<br />
<br />
=Aim= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards, we designed an Arduino compatible platform to allow easy reuse and access. As with the previous badge all code and design files are available.<br />
<br />
==Battery Warning==<br />
A very last minute battery (and connector) change on the badge due to a supplier problem meant two issues arose with the badge during EMF:<br />
<br />
* '''Always make sure to plug your battery in the right way round!''' The new battery connector allows you to connect it backwards. We did our best to mitigate this, but connecting it incorrectly will destroy the power management controller and prevent the badge from charging or running from the battery. It will still function perfectly using USB power. "Red" and "Black" are written next to the connector - please make sure to plug it in correctly.<br />
<br />
* '''Be careful not to short the battery connector wires!''' The new battery connector slightly exposes the wires when the battery is plugged in. If a metal object shorts the two wires, it can result in extreme battery damage. If we'd known this was such an issue before the event we would have applied protective material to it - we suggest covering the exposed connector in tape, sugru, blu-tack, or some other insulating material. Alternatively, simply unplug the battery when your badge is not in use!<br />
<br />
==Basic features and functions==<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
== How to get going ==<br />
=== Set up your environment ===<br />
* Plug your badge into your computer via USB<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* “git clone” or download TiLDA source code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE. <br />
* Now you have to change the sketchbook-folder to be the folder you just cloned. To do this use File | Preferences | “Set Sketchbook location”. On MacOS, this is Arduino | Preferences <br />
* Restart the Arduino IDE<br />
* Open sketch “EMF2014”<br />
* Set Tools | Board to MKe v0.333 (RTOS Core)<br />
* Set Tools | Port to correct port (you might have to research this - some operating systems like Windows require you to install drivers or become a member of a certain group)<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Woohoo - You just successfully uploaded code to your badge<br />
<br />
=== Your first “Hello world” app ===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
=== Why are things so different from standard Arduino code? ===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spend quite a lot of time to make the build-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== How to use the badge with pure Arduino code ===<br />
If you prefer you can always start from scratch without FreeRTOS or any of our code, just keep in mind that you won’t be able to receive messages via radio or use any of the API features we already added. Just start a new sketch in the Arduino IDE for that and get going. If you want to load the main firmware again just change the sketch to “EMF2014” and upload again.<br />
<br />
=== Debugging and Gotchas ===<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
=== Radio infrastructure ===<br />
The radio infrastructure is distributed between DKs. Every “gateway” has a Raspberry Pi with two Ciseco USB radios. We never had the chance to actually try it with a large number of badges in the same spot, so please don’t expect it to work perfectly.<br />
<br />
=== Your own wireless badge network ===<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
=== Contribute ===<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Hardware=<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3797TiLDA MKe2014-11-28T17:28:52Z<p>Jonty: </p>
<hr />
<div>The TiLDA MKe project, Code name "ElectroMagnetic Boogaloo", is being headed by [[User:Dpslwk|'RepRap' Matt]] and [[User:thinkl33t|Bob]]<br />
[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
Please Note: There are a couple of minor hardware and some firmware issues that might be affecting your badge. If you've let the magic smoke out of your charge controller or have tried to re-flash and ended up with nothing but a couple of dimly glowing lights then DO NOT DESPAIR -It's recoverable and fixes, documentation and lots of firmware are still being produced :)<br />
<br />
=Aim= <br />
The main aim of the 2014 badge is to give camp attendees an interesting bit of hardware to play with during the camp and experiment with afterwards, we designed an Arduino compatible platform to allow easy reuse and access. As with the previous badge all code and design files are available.<br />
<br />
==Battery Warning==<br />
'''Always make sure you plug your battery in the right way round!''' If you don't, the charge controller will let out its magic smoke and die / become damaged and die later. The badge itself will still work, but it wont have the ability to charge anymore. <br />
<br />
We think this is the cause of the charge controller issues a small number of badges had at the event was due to this mistake being made during final assembly on-site. <br />
<br />
'''Lithium Batteries are dangerous!''' While these batteries are better protected than the MK1 batteries, they are still scary. Do not short your battery, and if it starts bulging or gets punctured, '''DO NOT USE IT AGAIN''' and dispose of it properly.<br />
<br />
==Basic features and functions==<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
== How to get going ==<br />
=== Set up your environment ===<br />
* Plug your badge into your computer via USB<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* “git clone” or download TiLDA source code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE. <br />
* Now you have to change the sketchbook-folder to be the folder you just cloned. To do this use File | Preferences | “Set Sketchbook location”. On MacOS, this is Arduino | Preferences <br />
* Restart the Arduino IDE<br />
* Open sketch “EMF2014”<br />
* Set Tools | Board to MKe v0.333 (RTOS Core)<br />
* Set Tools | Port to correct port (you might have to research this - some operating systems like Windows require you to install drivers or become a member of a certain group)<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Woohoo - You just successfully uploaded code to your badge<br />
<br />
=== Your first “Hello world” app ===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
=== Why are things so different from standard Arduino code? ===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spend quite a lot of time to make the build-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== How to use the badge with pure Arduino code ===<br />
If you prefer you can always start from scratch without FreeRTOS or any of our code, just keep in mind that you won’t be able to receive messages via radio or use any of the API features we already added. Just start a new sketch in the Arduino IDE for that and get going. If you want to load the main firmware again just change the sketch to “EMF2014” and upload again.<br />
<br />
=== Debugging and Gotchas ===<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
=== Radio infrastructure ===<br />
The radio infrastructure is distributed between DKs. Every “gateway” has a Raspberry Pi with two Ciseco USB radios. We never had the chance to actually try it with a large number of badges in the same spot, so please don’t expect it to work perfectly.<br />
<br />
=== Your own wireless badge network ===<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
=== Contribute ===<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Hardware=<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3796TiLDA MKe2014-11-28T17:10:58Z<p>Jonty: </p>
<hr />
<div>The TiLDA MKe project, Code name "ElectroMagnetic Boogaloo", is being headed by [[User:Dpslwk|'RepRap' Matt]] and [[User:thinkl33t|Bob]]<br />
[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
Please Note: There are a couple of minor hardware and some firmware issues that might be affecting your badge. If you've let the magic smoke out of your charge controller or have tried to re-flash and ended up with nothing but a couple of dimly glowing lights then DO NOT DESPAIR -It's recoverable and fixes, documentation and lots of firmware are still being produced :)<br />
<br />
=Aim= <br />
The main aim of the 2014 badge is to give camp attendees live schedule updates and notifications. As with the original TiLDA we wanted to keep with an Arduino compatible platform that will allow badge hacking during and after the camp. As with the previous badge all code and design files are available.<br />
<br />
==Battery Warning==<br />
'''Always make sure you plug your battery in the right way round!''' If you don't, the charge controller will let out its magic smoke and die / become damaged and die later. The badge itself will still work, but it wont have the ability to charge anymore. <br />
<br />
We think this is the cause of the charge controller issues a small number of badges had at the event was due to this mistake being made during final assembly on-site. <br />
<br />
'''Lithium Batteries are dangerous!''' While these batteries are better protected than the MK1 batteries, they are still scary. Do not short your battery, and if it starts bulging or gets punctured, '''DO NOT USE IT AGAIN''' and dispose of it properly.<br />
<br />
==Basic features and functions==<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
== How to get going ==<br />
=== Set up your environment ===<br />
* Plug your badge into your computer via USB<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* “git clone” or download TiLDA source code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE. <br />
* Now you have to change the sketchbook-folder to be the folder you just cloned. To do this use File | Preferences | “Set Sketchbook location”. On MacOS, this is Arduino | Preferences <br />
* Restart the Arduino IDE<br />
* Open sketch “EMF2014”<br />
* Set Tools | Board to MKe v0.333 (RTOS Core)<br />
* Set Tools | Port to correct port (you might have to research this - some operating systems like Windows require you to install drivers or become a member of a certain group)<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Woohoo - You just successfully uploaded code to your badge<br />
<br />
=== Your first “Hello world” app ===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
=== Why are things so different from standard Arduino code? ===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spend quite a lot of time to make the build-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
<br />
=== How to use the badge with pure Arduino code ===<br />
If you prefer you can always start from scratch without FreeRTOS or any of our code, just keep in mind that you won’t be able to receive messages via radio or use any of the API features we already added. Just start a new sketch in the Arduino IDE for that and get going. If you want to load the main firmware again just change the sketch to “EMF2014” and upload again.<br />
<br />
=== Debugging and Gotchas ===<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
<br />
=== Radio infrastructure ===<br />
The radio infrastructure is distributed between DKs. Every “gateway” has a Raspberry Pi with two Ciseco USB radios. We never had the chance to actually try it with a large number of badges in the same spot, so please don’t expect it to work perfectly.<br />
<br />
=== Your own wireless badge network ===<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
=== Contribute ===<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Hardware=<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe&diff=3795TiLDA MKe2014-11-28T17:05:29Z<p>Jonty: </p>
<hr />
<div>The TiLDA MKe project, Code name "ElectroMagnetic Boogaloo", is being headed by [[User:Dpslwk|'RepRap' Matt]] and [[User:thinkl33t|Bob]]<br />
[[File:IMG_0474.jpg|500px|right|thumb|Front]]<br />
[[File:Badge_Front.png|right|thumb|Front]]<br />
<br />
[http://en.wikipedia.org/wiki/E_(mathematical_constant) Why MKe?]<br />
<br />
Please Note: There are a couple of minor hardware and some firmware issues that might be effecting your badge. If you've let the magic smoke out of your charge controller or have tried to re-flash and ended up with nothing but a couple of dimly glowing lights then DO NOT DESPAIR -It's recoverable and fixes, documentation and lots of firmware are still being produced :)<br />
<br />
=Aim= <br />
The main aim of the 2014 badge is to give camp attendees live schedule updates and notifications. As with the original TiLDA we wanted to keep with an Arduino compatible platform that will allow badge hacking during and after the camp. As with the previous badge all code and design files are available.<br />
<br />
==Battery Warning==<br />
'''Always make sure you plug your battery in the right way round!''' If you don't, the charge controller will let out its magic smoke and die / become damaged and die later. The badge itself will still work, but it wont have the ability to charge anymore. <br />
<br />
We think this is the cause of the charge controller issues a small number of badges had at the event was due to this mistake being made during final assembly on-site. <br />
<br />
'''Lithium Batteries are dangerous!''' While these batteries are better protected than the MK1 batteries, they are still scary. Do not short your battery, and if it starts bulging or gets punctured, '''DO NOT USE IT AGAIN''' and dispose of it properly.<br />
<br />
==Features and Functions==<br />
[[File:Badge_Back.png|right|thumb|Back]]<br />
* Torch mode - Press the light button next to the screen. It will only light up fully if it's hung upside down to avoid blinding<br />
* Snake<br />
* Tetris<br />
<br />
== How to get going ==<br />
=== Set up your environment ===<br />
* Plug your badge into your computer via USB<br />
* Download Arduino IDE 1.5.7 from http://arduino.cc/en/main/software#toc3<br />
* “git clone” or download TiLDA source code from https://github.com/emfcamp/Mk2-Firmware<br />
* Start the Arduino IDE. <br />
* Now you have to change the sketchbook-folder to be the folder you just cloned. To do this use File | Preferences | “Set Sketchbook location”. On MacOS, this is Arduino | Preferences <br />
* Restart the Arduino IDE<br />
* Open sketch “EMF2014”<br />
* Set Tools | Board to MKe v0.333 (RTOS Core)<br />
* Set Tools | Port to correct port (you might have to research this - some operating systems like Windows require you to install drivers or become a member of a certain group)<br />
** On MacOS this is will start /dev/tty.usbmodem with 4 digits, and change for each port<br />
** On Linux this is usually /dev/ttyACM0 but may be a higher number if you have other USB Serial devices<br />
* Hit the upload button<br />
* Wait<br />
* Woohoo - You just successfully uploaded code to your badge<br />
<br />
=== Your first “Hello world” app ===<br />
There’s a “HelloWorldApp.cpp” file in which you can play around. In order for it to show up on the Homescreen you have to uncomment line 51 in AppManager.cpp and flash the changed code to the badge. Great app pull requests are appreciated!<br />
<br />
If you are still using the Arduino IDE at this point, note that it will not let you edit the .cpp and .h files that are needed to create Apps for the badge. To force the IDE to re-compile/re-read any files you've edited using an external editor, make sure to go to the File -> Preferences dialog box, and check the "Use external editor" checkbox.<br />
<br />
=== Why are things so different from standard Arduino code? ===<br />
We’re using a library called FreeRTOS that allows us to multitask - something that’s normally not possible with standard Arduino code. This allows us to run multiple tasks at the same time. FreeRTOS uses preemptive scheduling to switch between the task. Due to this we have to be very careful about how we do some things. For example we can’t just define interrupts for buttons in every task (imagine the mess!) or write to the serial port directly (your task might stop in the middle of the message). <br />
<br />
We’ve also spend quite a lot of time to make the build-in components as easy to use as possible without having every task to write lots of boilerplate code. If you feel like using the build-in components on the badge, chances are we already wrote a wrapper for them that is already used by one of the other tasks. <br />
<br />
Have a look at the “Documentation” section in this document for a full list of API functions. You will avoid a lot of headaches if you stick to those.<br />
=== How to use the badge with pure Arduino code ===<br />
If you prefer you can always start from scratch without FreeRTOS or any of our code, just keep in mind that you won’t be able to receive messages via radio or use any of the API features we already added. Just start a new sketch in the Arduino IDE for that and get going. If you want to load the main firmware again just change the sketch to “EMF2014” and upload again.<br />
=== Debugging and Gotchas ===<br />
* The USB serial is set up to 115200 baud. There are lots of terminals that can connect to them. See below for how to enable the debug logging.<br />
* If you can’t revive a badge you can short the two erase pins and press the reset button while holding it down.<br />
* Avoid busy waiting, use FreeRTOS queues and Tilda::delay() instead<br />
* Don’t use low level functions like interrupts or serial ports directly unless you really, really know how FreeRTOS will handle them. For general logging you can use Tilda::log()<br />
* If sending code to the badge using the Arduino IDE "Upload" button fails, even though the /dev/ttyACM0 (linux com port) is there, just retry, twice if neccessary.<br />
<br />
=== Code structure ===<br />
* FreeRTOS has the concept of “Tasks” which work like threads. We’ve wrappered them in a class called “Task” (for background stuff) and “Apps” (for foreground, one-at-a-time things)<br />
* Everything needs to be in the main EMF2014 folder. Subfolders are not allowed. This is an Arduino IDE restriction :(<br />
=== Radio infrastructure ===<br />
The radio infrastructure is distributed between DKs. Every “gateway” has a Raspberry Pi with two Ciseco USB radios. We never had the chance to actually try it with a large number of badges in the same spot, so please don’t expect it to work perfectly.<br />
<br />
=== Your own wireless badge network ===<br />
[[DIY TiLDA Badge Network]] has instructions on how to setup your own private badge network using a RaspberryPi and two Ciseco radios.<br />
<br />
=== Contribute ===<br />
Send us a pull request via [https://github.com/emfcamp/Mk2-Firmware GitHub] - We’ll do our best to review and merge the good ones during EMF so others can use them.<br />
<br />
=Hardware=<br />
<br />
The following hardware has been included on the badge.<br />
<br />
* [http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx Atmel ATSAM3X8E]<br />
** This is the same chip as the [http://arduino.cc/en/Main/ArduinoBoardDue Arduino Due] and gives us the base platform for the badge<br />
** 32bit ARM Cortex M3 * 84MHz<br />
** 512KBytes Flash RAM<br />
** 96KBytes of SRAM<br />
* A 128x64 pixel monochrome LCD display<br />
* [http://shop.ciseco.co.uk/srf-wireless-rf-radio-surface-mount/ Ciseco SRF Radio]<br />
** 868Mhz RF Transceiver<br />
** Simple UART interface<br />
** Low power sleep mode<br />
* [http://www.invensense.com/mems/gyro/mpu6050.html MPU-6050] 3-axis Accelerometer and 3-axis gyro<br />
** I2C interface<br />
** Tri-Axis angular rate sensor (gyro) with a sensitivity up to 131 LSBs/dps and a full-scale range of ±250, ±500, ±1000, and ±2000dps<br />
** Tri-Axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g<br />
** Digital Motion Processing™ (DMP™) engine offloads complex MotionFusion, sensor timing synchronisation and gesture detection<br />
* PMIC & LiPo<br />
* Joystick<br />
* Buttons<br />
* RGB LEDs<br />
* IR<br />
* Arduino Headers<br />
* Pads for wearable tech<br />
<br />
= Firmware Documentation =<br />
== Debugging ==<br />
===Enabling the USB serial debug log messages===<br />
To enable the debug logging you must uncomment the following line in [https://github.com/emfcamp/Mk2-Firmware/blob/master/hardware/emfcamp/sam/libraries/debug/debug.h#L42 hardware/emfcamp/sam/libraries/debug/debug.h]<br />
<br />
// Enable debug task and output<br />
// #define DEBUG 1<br />
<br />
===Tilda::log(String text)===<br />
<br />
This logs “text” to the serial console. To read it connect to it via the Arduino IDE Serial Monitor. Don’t use “SerialUSB.println” or similar -- it’s not thread-safe and you might end up with utter nonsense.<br />
<br />
===Debugging using the JTAG interface===<br />
The JTAG interface on the board provides powerful debugging facilities like breakpoints, backtraces, dumping memory, inspecting variables, checking task states, catching exeptions etc. To make this to work requires additional hardware and software, see [[TiLDA Debugging using JTAG]].<br />
<br />
== Buttons ==<br />
The badge has 8 buttons: Up, Down, Left, Right, Center (on the joystick), A, B and Light. You can use arduino-style “digitalRead(BUTTON_RIGHT)” to read the current status of any button, but you can’t define your own interrupt (because we already did that). This doesn’t mean you can’t wait for a certain button to be pressed, it just means you have to approach it slightly differently:<br />
<br />
Example: A simple app displaying the button code<br />
void ButtonApp::task() {<br />
ButtonSubscription allButtons = Tilda::createButtonSubscription(LIGHT | A | B | UP | DOWN | LEFT | RIGHT | CENTER);<br />
<br />
while(true) {<br />
Button button = allButtons.waitForPress(1000);<br />
if (button == A) {<br />
debug::log(“You pressed button A”);<br />
} else if (button == LEFT) {<br />
debug::log(“You pressed LEFT”);<br />
} else if (button == NONE) {<br />
debug::log(“No button has been pressed in 1000ms”); <br />
}<br />
}<br />
}<br />
<br />
<br />
===ButtonSubscription Tilda::createButtonSubscription(<buttons>)===<br />
<br />
Registers a subscriptions for a defined set of buttons and returns a ButtonSubscription. Multiple Buttons can be combined via “|” (see example above). One button can not be subscribed by more than 10 subscriptions (which shouldn’t really happen, but keep it in mind). <br />
<br />
Don’t use this function in a constructor, it requires FreeRTOS to be running. Using it inside the task() function is the only safe place for it.<br />
<br />
===Button ButtonSubscription::waitForPress(TimeInTicks timeout)===<br />
<br />
This is normally called in a loop. It causes the task to block until one of the buttons has been pressed. If the timeout occurs before any button has been pressed “NONE” will be returned. <br />
<br />
===ButtonSubscription::waitForPress()===<br />
<br />
The same as above, but without the timeout.<br />
<br />
===ButtonSubscription::clear()===<br />
<br />
This should be called after an App has been suspended, just before it’s going to be resumed. It causes the Queue to be cleared which could otherwise lead to buttons being reported that have been pressed while other apps were in the foreground. Have a look at the FlashLightApp for an example.<br />
<br />
==LEDs==<br />
===Tilda::setLedColor(Led led, Color color);===<br />
===Tilde::setLedColor(Color color);===<br />
<br />
Sets the color of all or one led. Color is an object that takes red, green and blue as a value between 0 and 255 each. If no led is defined both leds will be set to the same color.<br />
<br />
Example: A simple color-changing task<br />
void ColorfulTask::task() {<br />
while(true) {<br />
Tilda::setLedColor(LED1, {255, 0, 0}); // Red<br />
Tilda::setLedColor(LED2, {0, 255, 0}); // Green<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 255, 0}); // Green<br />
Tilda::setLedColor(LED2, {0, 0, 255}); // Blue<br />
Tilda::delay(300);<br />
Tilda::setLedColor(LED1, {0, 0, 255}); // Blue<br />
Tilda::setLedColor(LED2, {255, 0, 0}); // Red<br />
Tilda::delay(300);<br />
}<br />
}<br />
<br />
==Display==<br />
<br />
The Display Library is based on GLCDv3 (http://playground.arduino.cc/Code/GLCDks0108), docs (http://code.google.com/p/glcd-arduino/source/browse/trunk/glcd/doc/GLCD_Documentation.pdf) but adapted to support our screen. The Init routine is called in the setup, and the LCDTask takes care of ensuring the screen is updated every 40ms if required (Unlike the original GLCD library, screen updates are decoupled from the graphics routines.)<br />
<br />
Also available is M2tklib (https://code.google.com/p/m2tklib/) which is a nice toolkit library. Further details on using this will come later, but expect the main loop to be handled for you, and just passing the menu structure you require for your app.<br />
<br />
Right now, you can call the GLCD functions directly with GLCD.DrawBitmap() for example. This is going to change to be accessed through the GUITask class in the near future, to ensure only one task at a time writes to the screen. Expect this to be simply GUITask in place of GLCD, along with a registering a redraw call back to GUITask. The bitmap format, by the way, is rather unconventional but there are a couple of utility scripts to convert popular formats down in the hacking section below - you can grab the SponsorsApp.h as an example and swap out the bitmap array with one of your choosing.<br />
<br />
Extra features that are included, GLCD.SetRotation() will handle rotation of the screen for you, and GLCD.CurrentWidth() and GLCD.CurrentHeight will give you the correct Width and Height for the current orientation. GLCD.Width and GLCD.Height constants are not available, and the GLCD predefined Text areas will not be rotated for you, if you require this define your own text areas.<br />
<br />
Note that one function was not ported to the badge version of GLCD, "Printf", you'll have to cope without it.<br />
<br />
== Sound == <br />
There's a piezo on the board, but we haven't added code for it to the current firmware. Pull requests are very welcome!<br />
<br />
== IMU ==<br />
=== Tilda::getOrientation ===<br />
returns " ORIENTATION_HELD", "ORIENTATION_RIGHT" (joystick to the right of the screen), "ORIENTATION_HUNG" or "ORIENTATION_LEFT"<br />
<br />
== Flash Storage ==<br />
We have 2mb of flash storage, but we're not using it in the main firmware - Please get this working!<br />
== Data: Schedule ==<br />
===Tilda::getDataStore().getSchedule(day, location) ===<br />
== Date: Weather Forecast ==<br />
===Tilda::getDataStore().getWeatherForecast()===<br />
== Radio ==<br />
There's no way of sending messages in the current version of the firmware, sorry :(<br />
<br />
== Time ==<br />
<br />
=== Tilda::delay(uint16_t delayInMs) === <br />
<br />
Works like Arduino’s delay(), but is FreeRTOS-safe. It’s safe to use this function before FreeRTOS has started.<br />
<br />
=== tilda::getClock() ===<br />
<br />
Returns an instance of https://github.com/MarkusLange/Arduino-Due-RTC-Library/blob/master/rtc_clock.h<br />
<br />
==Settings==<br />
===uint16_t tilda::getBadgeId()===<br />
<br />
<br />
==2.12. Battery==<br />
===float TiLDA::getBatteryVoltage()===<br />
Returns the current voltage as a float<br />
<br />
===uint8_t TiLDA::getBatteryPercent()===<br />
Returns the current voltage as a percentage<br />
<br />
===uint8_t TiLDA::getChargeState()===<br />
Returns the charge state<br />
<br />
0 Charging<br />
1 Not Charging<br />
<br />
=Hacking=<br />
To use our board definition you will need to first get the Arduino 1.5.7 IDE from [http://arduino.cc/en/Main/Software#toc3 here]<br/><br />
Next you can download the TiLDA MKe Firmware project from either the [https://github.com/emfcamp/Mk2-Firmware github repo] or via [https://github.com/emfcamp/Mk2-Firmware/archive/master.zip direct download]<br/><br />
Now copy the "hardware" folder to your Sketchbook folder, this is usually ~/Sketchbook/<br><br />
or<br/><br />
Alternative option is to set the Arduino 1.5.7 sketchbook folder to the Mk2-Firmware directory.<br/><br />
<br />
Start the Arduino IDE and your will be able to select TiLDA MKe v0.333 for the Tools->Board menu<br />
<br />
* Draft 3d print-able and laser-able case files [http://www.thingiverse.com/thing:436815 here]<br />
* A Python script (via [https://twitter.com/trotmaster99 @trotmaster99]) that converts a monochrome bitmap image into a format suitable for the Tilda can be found [http://pastebin.com/8XeazQjT here].<br />
* A similar script in Perl to create TiLDA MKe fullscreen bitmaps from XBM: -<br />
<div style ="height:200px;overflow-x:hidden;overflow-y:auto;border: 4px solid orange;"><br />
'''xbm2mke.pl by [[User:Msemtd]]'''<br />
<nowiki><br />
#!perl -w<br />
use strict;<br />
# Little script to convert a regular XBM to TiLDA MKe bitmap<br />
# only tested with fullscreen bitmaps!<br />
# Hot file handle magic...<br />
select((select(STDERR), $| = 1)[0]);<br />
select((select(STDOUT), $| = 1)[0]);<br />
sub t(@);<br />
sub d($);<br />
sub chug($);<br />
my $f = shift;<br />
#~ $f = 'blankish.xbm' if not $f;<br />
if(not defined $f or not $f =~ /^(.*)\.xbm$/i){<br />
die "Usage: gimme an XBM file dude!\n";<br />
}<br />
my $name = $1;<br />
t "Reading file '$f'...";<br />
my $data = chug($f);<br />
t "OK";<br />
my @lines = split /^/, $data;<br />
@lines = grep{chomp; s/^\s+//; s/\s+$//; length;} @lines;<br />
#~ t d \@lines;<br />
my($width, $height) = (0,0);<br />
my @head = @lines[0..5];<br />
foreach(@head){<br />
if(/_width\s+(\d+)/){$width = $1;}<br />
if(/_height\s+(\d+)/){$height = $1;}<br />
}<br />
t "width x height = $width x $height";<br />
my @k;<br />
foreach(@lines){ push @k, split /,/; }<br />
@k = grep { s/^.*(0x[0-9A-Fa-f]{1,2}).*$/$1/o; /(0x[0-9A-Fa-f]{1,2})/o } @k;<br />
#~ t d \@k;<br />
my $bc = scalar(@k);<br />
t "Pulled out $bc hex bytes";<br />
if($bc != $width * $height / 8) {<br />
die "byte count $bc does not match that expected for w x h";<br />
}<br />
t "OK - reorder bytes for MKe bitmap";<br />
my $wb = int($width/8) + (($width & 0x07) ? 1: 0);<br />
t "width in whole bytes for $width pixels = $wb";<br />
my @mke;<br />
for(my $col = 0; $col < $wb; $col++){<br />
for(my $row = $height - 1; $row >= 0; $row--){<br />
my $idx = ($row * $wb) + $col;<br />
my $val = $k[$idx];<br />
#~ t "Column $col + Row $row = idx $idx = $val";<br />
push @mke, $val;<br />
}<br />
}<br />
my $out = "static const uint8_t ".uc($name)."_BM[] = {\n"<br />
." $width, // width\n"<br />
." $height , // height\n";<br />
#~ $out .= join(", ", @mke);<br />
while(scalar @mke){<br />
$out .= join(", ", splice(@mke, 0, 16)).",\n";<br />
}<br />
$out .= "};\n";<br />
# meh, just print it out<br />
t $out;<br />
<br />
sub t(@) {<br />
foreach (@_) {<br />
print STDOUT "$_\n";<br />
}<br />
}<br />
sub d($) {<br />
require Data::Dumper;<br />
my $s = $_[0];<br />
my $d = Data::Dumper::Dumper($s);<br />
$d =~ s/^\$VAR1 =\s*//;<br />
$d =~ s/;$//;<br />
chomp $d;<br />
return $d;<br />
}<br />
sub chug($) {<br />
my $filename = shift;<br />
local *F;<br />
open F, "< $filename" or die "Couldn't open `$filename': $!";<br />
local $/ = undef;<br />
return <F>;<br />
} # F automatically closed<br />
<br />
</nowiki><br />
</div><br />
<br />
<span id=github></span><br />
<br />
= Source =<br />
<br />
All the source code and designs are on openly available on Github:<br />
<br />
* [https://github.com/emfcamp/Mk2-Hardware Hardware] - the full board design<br />
* [https://github.com/emfcamp/Mk2-Documentation Documentation] - a dump of relevant parts datasheets<br />
* [https://github.com/emfcamp/Mk2-Firmware Firmware] - source code for the badge software<br />
* [https://github.com/emfcamp/Mk2-Software Software] - server-side software for the network<br />
<br />
If you want to help, point your IRC client to #tilda on Freenode.<br />
<br />
[[Category: Badges]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe_Competition&diff=3794TiLDA MKe Competition2014-11-28T14:03:40Z<p>Jonty: </p>
<hr />
<div>Now that EMF is over and you've returned home, its time to dig out your EMF badge and start playing!<br />
<br />
We'll be rewarding the best hack using the badge with '''two tickets to EMF 2016''', and '''two tickets to the one-day event in 2015'''. We might also have '''other prizes available''' for hacks in different categories!<br />
<br />
==Submitting your hack==<br />
Email [mailto:competition@emfcamp.org competition@emfcamp.org] with the details of your hack, either linking to an existing website or attaching documentation to the email.<br />
<br />
'''Submissions close on the 31st March 2015 at midnight''', with the winners being announced on April 15th.<br />
<br />
==My badge is broken so I can't enter!==<br />
If your badge was one of the few that suffered a hardware failure, [mailto:badge@emfcamp.org get in touch] and we'll be happy to replace it so you can take part in the competition.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=TiLDA_MKe_Competition&diff=3793TiLDA MKe Competition2014-11-28T14:01:30Z<p>Jonty: Created page with "Now that EMF is over and you've returned home, its time to dig out your EMF badge and start playing! We'll be rewarding the best hack using the badge with '''two tickets to E..."</p>
<hr />
<div>Now that EMF is over and you've returned home, its time to dig out your EMF badge and start playing!<br />
<br />
We'll be rewarding the best hack using the badge with '''two tickets to EMF 2016''', and '''two tickets to the one-day event in 2015'''. We might also have '''other prizes available''' for hacks in different categories!<br />
<br />
==Submitting your hack==<br />
Email [mailto:competition@emfcamp.org competition@emfcamp.org] with the details of your hack, either linking to an existing website or attaching documentation to the email.<br />
<br />
'''Submissions close on the 31st March 2015 at midnight''', with the winners being announced on April 15th.<br />
<br />
==My badge is broken!==<br />
If your badge was one of the few that suffered a hardware failure, [mailto:contact@emfcamp.org get in touch] and we'll be happy to replace it so you can take part in the competition.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Accounting&diff=3785Accounting2014-10-22T15:51:16Z<p>Jonty: </p>
<hr />
<div>The EMF 2014 account breakdown is yet to be published due to ongoing discussions with suppliers.<br />
<br />
If you would like to receive an email when the accounts are ready please '''[https://docs.google.com/forms/d/1jTV0fYtV0A-MEUemzIM06IGN-sWZX4hdeVvy5GwR5_A/viewform fill in this form]'''.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Accounting&diff=3784Accounting2014-10-22T15:51:00Z<p>Jonty: </p>
<hr />
<div>The EMF 2014 account breakdown is yet to be published due to ongoing discussions with suppliers.<br />
<br />
If you would like to receive an email when the budget is ready please '''[https://docs.google.com/forms/d/1jTV0fYtV0A-MEUemzIM06IGN-sWZX4hdeVvy5GwR5_A/viewform fill in this form]'''.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Budget&diff=3783Budget2014-10-22T15:50:37Z<p>Jonty: Jonty moved page Budget to Accounting: Whoops, this is accounting not budget. Sorry.</p>
<hr />
<div>#REDIRECT [[Accounting]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Accounting&diff=3782Accounting2014-10-22T15:50:36Z<p>Jonty: Jonty moved page Budget to Accounting: Whoops, this is accounting not budget. Sorry.</p>
<hr />
<div>The EMF 2014 budget has yet to be published due to ongoing discussions with suppliers.<br />
<br />
If you would like to receive an email when the budget is ready please '''[https://docs.google.com/forms/d/1jTV0fYtV0A-MEUemzIM06IGN-sWZX4hdeVvy5GwR5_A/viewform fill in this form]'''.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Accounting&diff=3781Accounting2014-10-22T15:44:03Z<p>Jonty: Created page with "The EMF 2014 budget has yet to be published due to ongoing discussions with suppliers. If you would like to receive an email when the budget is ready please '''[https://docs...."</p>
<hr />
<div>The EMF 2014 budget has yet to be published due to ongoing discussions with suppliers.<br />
<br />
If you would like to receive an email when the budget is ready please '''[https://docs.google.com/forms/d/1jTV0fYtV0A-MEUemzIM06IGN-sWZX4hdeVvy5GwR5_A/viewform fill in this form]'''.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Feedback&diff=3693Feedback2014-09-10T16:18:08Z<p>Jonty: </p>
<hr />
<div>{{link-banner}}<br />
Please let us know what went well and what didn't go well at EMF this year. We really do care about your feedback and we'll try and improve this for next time.<br />
<br />
Add your feedback below:<br />
<br />
== Good Stuff ==<br />
<br />
* Location<br />
* Badges<br />
* Variety of talks [+1]<br />
* Showers [+∞]<br />
* Hand washing facilities<br />
** putting the showers (with hot water in handbasins) next to toilets v.good<br />
* Parking<br />
* Shuttle trailer to car park<br />
** ... and shuttle to BLY railway station. Made coming by public transport a doddle.<br />
* Power & data infrastructure - pretty much rock solid throughout! [+2]<br />
* Speedy response of volunteers/organisers to problem resolution<br />
* Service at the bar was good (while the drinks lasted), and it was very nice to have ''multiple'' indoor social spaces, esp for people who wanted a quieter lounge as well as louder bar.<br />
** Being able to check beer availability on the till website was awesome!<br />
** The lounge was great - the decorations, beanbags, no-shoes rule and power were a great combination<br />
* Floor panel roads [+5]<br />
* String lights (cut through to showers was awesome!) [+2]<br />
* Ability to hire tables/chairs/marquees/hay bales etc. - were all good quality, too. [+2]<br />
* Kids workshops [+2]<br />
* Arcade! [+1]<br />
* Friendliness of other attendees [+1]<br />
* First aid [+1]<br />
* Shop - selling books of speakers was a really nice idea, and it was good to talk to speakers & do signing there afterwards.<br />
* That spinning music installation.<br />
* Lighting - I didn't have to turn my torch on at all, but it was still dark enough in my tent to sleep.<br />
* Club Mate.<br />
* Ring making workshop<br />
* Lake was pretty<br />
* Supportive atmosphere for speakers and very nice feedback afterwards<br />
* Water: plentiful flow, tasty water, cool dispensers [+1]<br />
** Hand soap by taps (udders?)<br />
* Keeping toilet paper supplies topped up in all the toilets<br />
* Nice choice of real ales and proper cider<br />
* Lasershow + Chiptunes in Tent A<br />
* Tschunk<br />
* Everything that Dimitri brought along [+1]<br />
* EMF CTF: Like getting lock pickers to cook your food, playing IRL replay,relay and pre-play attacks and memory corruption, sadly no real-life cross-site scripting :)<br />
* Tea and food provided during set up really helped me keep going.<br />
* How to crimp ethernet cable sheets were brilliant. They made sure everyone was using the same standard and anyone new to crimping could carry them to remember the order.<br />
* There were lots of crimping tools and wire strippers to borrow during set up.<br />
* Vehicles: there were enough to get stuff around the site but not too many that I was worried about getting run over.<br />
* EMF hi vis jackets were awesome.<br />
* Simon Singh [+1]<br />
* Till system in the bar - I found it very quick and easy to use after about 10 mins practice.<br />
* Cashback in the bar.<br />
* Dutch food.<br />
* Laser cut items for sale.<br />
* Badge creations competition is a nice way to encourage people to tinker with the badges and share the results.<br />
* Wristbands<br />
** Fabric was much more comfortable than paper/Tyvek/plastic, and they were pretty too!<br />
* T-shirts<br />
** Good choice of colours, sizes and fits, awesome design<br />
<br />
== Stuff that could be improved ==<br />
<br />
* Buy more beer! [[User:Russ|Russ]] ([[User talk:Russ|talk]]) [+1]<br />
** No firkins next time, kils only! --[[User:Sde|Sde]] ([[User talk:Sde|talk]])<br />
* Toilets... 'nuff said! [[User:AndyB|AndyB]] ([[User talk:AndyB|talk]]) [+2]<br />
** +1, I also suggest adding plastic bags/bins into the toilets, for (female) sanitary waste ([[User:Will-Do|Will-Do]])<br />
** Agreed - I've seen portakabins (like the shower blocks) that containing proper flushing loos. They're ''much'' less stinky and likely to block up than the portaloos we had, which didn't always seem willing to drop their loads into their collection tanks, leading to nastiness and health hazards (even without the pumping contractor being rubbish)<br />
*** This was actually what we wanted, but they're tremendously expensive. Suggestions for vendors welcome! --[[User:Jonty|Jonty]]<br />
** Additionally, LIGHTS in the toilets. Having to use my phone / badge as a torch to see what was going on while i cleaned off the toilet before sitting down was particularly difficult. [[User:Thinkl33t|Thinkl33t]] ([[User talk:Thinkl33t|talk]]) 20:05, 1 September 2014 (UTC)<br />
** thunderboxes2go.co.uk are good and know how to handle local authority problems, they have done shambala for 10+ years - high enough capacity to not need emptying during the event [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
** Maybe ask Cambridge & District CAMRA who provided the toilets for Cambridge 41st beer festival - they had some fairly nice flushing toilets which came on a trailer, a bit like the posh wash showers. I think Jonty mentioned that a lot of providers were put off by the fact that we're a festival. Well, if these guys are ok with providing for a beer festival, they must be pretty brave! -[[User:Alecjw]]<br />
** Definite vote for the trailer-style flushing toilets, with multiple cubicles (+sinks, lights and mirrors) on one tow-along trailer, just like the showers. I've seen these at MANY festivals - though, granted, usually only in 'posh' camping/press/VIP areas. Should be possible if you manage to convince the providers that we're not a rowdy bunch of drunken teenagers!<br />
** A clue to the problem with the chemical toilets is in the name: no chemical sanitiser/deodoriser was used in any toilet I tried. Adding Elsan or similar to the toilets would probably have made them much more acceptable. [[User:PhilSwinbank|PhilSwinbank]] ([[User talk:PhilSwinbank|talk]]) 22:18, 3 September 2014 (UTC)<br />
* Make sure that drinking water is clearly labelled as such<br />
* More food and drink options<br />
** Eg. non-caffeine / low or no sugar options<br />
** Chips!<br />
** Jacket potato vendor<br />
** Healthy 'green' food<br />
** also possibly going on later, a lot of the places shut up shop quite early.<br />
** queues at Pizza place were huge, wait time was >1hour at lunch time<br />
** A late night vendor would be fantastic - doesn't have to be fancy food, but just something hot to eat after 9pm [+4]<br />
** Soft drinks! [+2]<br />
*** I helped organise a ball at university. Coca Cola sponsored us and provided very cheap (maybe free) drinks to the event. Before next time, someone remind me to look into them doing this for EMF [[User:MatS|MatS]] ([[User talk:MatS|talk]]) 14:02, 4 September 2014 (UTC)<br />
* Survey positions of lanes/tents/DKs as early as possible before items arrive and mark out.--[[User:Sully|Sully]] ([[User talk:Sully|talk]]) 12:06, 1 September 2014 (UTC)<br />
** This was planned but we were let down by the rather poor state of mobile GIS software. <br />
*** there are multiple open source solutions for mapping, try https://umap.openstreetmap.fr/en/ or reach to out myself or #openstreetmap, there are many OSM'ers in the UK, [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]]).<br />
* Similar to this, measure for fence panels and drop stillage appropriately, to avoid the need to carry loads of them right up the camping field by hand<br />
* Make it longer! There was loads of cool stuff I didn't have change to check out :( After all that work everyone does, it was a shame I couldn't experience it all! ([[User:Chewie|Chewie]]) ((I still say make it a week long ;) ([[User:BuildTheRobots|Fligg]]))<br />
* Visibility of presentations in tents (brighter projectors/darker tents??) ([[User:StuartL]]) [+3]<br />
* Use more plasma screens in stages instead of projectors ([[User:Markp]]). Or (better, as then the speaker can point to things) black fabric shades for the screen or marquee roof<br />
** Next time dark tents. This was a total nightmare, sorry. --[[User:Jonty|Jonty]] <br />
*** Marquees with a blackout end are not unusual: the hire company perhaps should have advised on this? -[[User:Dermot|Dermot]] <br />
*** Also I have experience producing seminar-type recordings for DVDs and am willing to help out with this next time. With controlled lighting and at least one extra camera on each stage you can ramp up the production values. If there is the will to do it and enough volunteers. And I'm absolutely not criticising what was done this year! -[[User:Dermot|Dermot]]<br />
* washing points over drains/soakaway so the ground doesn't get muddy ([[User:Chewie|Chewie]]) [+4]<br />
* Mark out/allocate spaces for villages who had pinpointed locations on maps ([[User:Markp]]) [+2]<br />
** Space needed by villages was very hard to judge before they were set up, especially once non-village campers started on site ([[User:BuildTheRobots|Fligg]]) <br />
* Improved arrangements for washing and washing up (and handling the waste water from that) [+1]<br />
* Provide sanitizer gel dispensers at water points and near loos [+2]<br />
* Have the schedule linked off the EMF main page<br />
** It was, but not on the First day...we forgot! See "Programme" at the top of the main website. --[[User:Jonty|Jonty]]<br />
* Distribute and display paper schedules (even if their might be some last-minute changes) [+3]<br />
** They were supposed to be available at the info tent, not sure what happened there. --[[User:Jonty|Jonty]]<br />
** Or have small screens at the entrances to tents showing what's currently on & what's next.<br />
*** We wanted to do this but simply ran out of time. --[[User:Jonty|Jonty]]<br />
* Much more workshop activity (more hands-on electronics and physical making) [+6]<br />
** Next time: Many more workshop tents. We totally underestimated availability and demand. [+1] --[[User:Jonty|Jonty]]<br />
* Do have component vendors (maybe at their cost for marquee/power/space)<br />
** This is very difficult without a clear list of what will sell, as CPC was arranged to appear but wanted advisement ([[User:Stanto]])<br />
*** Would the (longer and with more repeats next time) workshop list work as advisement? Could workshop leaders be asked to provide suggestions for components that would be good to have available on site after their workshop?<br />
* Pick a flatter site (for ease of disabled access)<br />
* Ask speakers for bio's to include with their abstracts. Given them an abstract length up-front instead of editing it in an ad hoc way. Confirm acceptance to speakers and workshop organisers earlier.<br />
** Do this after talks have been accepted. I didn't write my talk so didn't know details until I got the OK.<br />
** The CFP was a bit of a nightmare this year, we'll certainly be doing this in 2016. --[[User:Jonty|Jonty]]<br />
* Make and enforce a clear music curfew (say from midnight or 1am or 2am to 8 or 9am or 10am), to defend those sleeping from (eg) the technoevangelists and the drunk [+4]<br />
** Perhaps try to select a site next time where we can make part of the site to be a quiet area, eg a part surrounded by trees for natural sound insulation. Then enforce a noise curfew there. I'm not keen on the idea of having a noise curfew covering the entire camp though. [[User:Alecjw]] [+1]<br />
** Seconding enforced quiet/family camping area, but no overall noise curfew. It didn't take long to get away from the worst noise, and the end of the field by the kids' area was incredibly quiet (though strangely empty!!)<br />
** Well, not quite - I need sleep to function, so camped in the quiet area - a nearby group thought 6:30am was the right time to turn on their music system. Not so good.<br />
* Loos not so near food vendors (pong + visible urinals offputting) [+5]<br />
* stronger enforcement/signage of quiet camping area [+5]<br />
* an explicit invitation (with clear instructions) to report Code of Conduct violations in open ceremony, brochure, Twitter, etc. We had no direct reports to Team Comfort, but several anecdotal tweets after the event -- when it's much too late. [[User:Martind|Martind]] ([[User talk:Martind|talk]]) 20:58, 1 September 2014 (UTC) [+1]<br />
* quieter, less-enclosed and more spacious bar (I suffer from social anxiety when I'm closed in with crowds, so I had a very sober emf!). [[User:Jane C|Jane C]]<br />
** perhaps an outdoor seating area if a larger marquee is too costly.<br />
*** There was an outdoor seating area set back to the right of the bar under a marquee, however the marquee vendor put it in the wrong place a day late, so wasn't as obvious, and didn't get hay bales until Saturday evening. --[[User:Jonty|Jonty]]<br />
* use our collective knowledge of technology to sort accessibility issues <br />
**ring-fence money for things like closed-loop in the stages early on. <br />
**ask people about their access requirements much earlier on - e.g. when they buy a ticket - so that there is more time to meet these requirements (or reach a workable compromise)<br />
**Build some kind of working system for preventing able-bodied people from using the disabled loos and showers (radar keys that only work when the loo is empty?) [[User:Jane C|Jane C]]<br />
***Disagree with this as it reduces overall toilet/shower bandwidth, but would wholly agree with a solution whereby those who could only use limited facilities (disabled, families, etc) could queue-jump into those facilities the moment they because available. [[User:StuartL|StuartL]]<br />
*** I found it a bit odd that no-one was using the disabled shower. Sure, disabled people should have priority (queue jump), i thought, but if there's noone with a disability waiting, why not use it? Although I suppose if we operate it that way, the expected waiting time for a disabled person is in some cases higher than that of an able bodied person... (my intuition says that this happens when (number of people in queue)<(number of showers) but I haven't verified this) [[User:Alecjw]]<br />
* Info desk didn't seem to have the details wrt. volunteers, so when I volunteered I was sent out and found I wasn't needed. Suggest splitting the job - having a volunteer team leader (or several, in shifts) whose job it is to know who is where and also to make sure nobody gets stuck on a gate for 12 hours (eg. rotating people to more interesting places every couple of hours). ([[User:TonyHoyle|TonyHoyle]])<br />
** There was a separate volunteer manager in the same tent, this should not have happened. Sorry about that. --[[User:Jonty|Jonty]]<br />
* Also similar to this, a register of 'on call' people - excess volunteers who can deal with sudden demands for people (esp. in the case of fire I can imagine this would be extremely useful - you'd potentially need to cordon off a largish area very quickly, and that takes people. More mundane reasons would be a talk/workshop accumulating a large queue that needs managing). ([[User:TonyHoyle|TonyHoyle]])<br />
** There were shifts for people to be "on call" but they weren't obvious. We'll make sure this is easier. --[[User:Jonty|Jonty]]<br />
** with earlier (/working) workshop sign-up, I would have put myself on call - instead I was waiting to hear what workshops would be available when.<br />
* add GPS or other location aware technology like BTLE/iBeacon to the badges for automatic now/next notifications [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]]).<br />
* Locking wristbands that don't get any tighter. [+1]<br />
* Having a tent for Badge Operations would be pretty handy - similar size to the workshop tent, that could be set up as a production line / fixing area if needed. If not (hopefully) it would be a rolling workshop area for people to work of hacking their badges, writing new software, adding hardware etc. ~~<br />
* Floor panel walkways were very slippery in the morning after rain, not sure if there's someway this can be improved<br />
**Sprinkling some coarse sand on them might help. [[User:Moem|Moem]] ([[User talk:Moem|talk]])<br />
* Better info on the bus between EMF <-> Bletchley so we know when they're running (alt: can we put GPS tracking on the buses?)<br />
* The buses were quite cramped so it was hard for people to get large bags through seats<br />
* More space between caterers and generator - the plant was right in the middle of prime catering space. --[[User:Nick|Nick]]<br />
* Appoint a (i.e. volunteer someone as) project manager to draw up a plan (Gantt chart!?) of when everything's arriving and leaving (to the extent known) and what resources (telehandler, buggy, number of people) are needed. We'll never stick to the plan and things will arrive early/late run off schedule but the same person can adjust the plan to control the chaos during build-up, take-down and the event. Chuck them out of the way in a tent managing things rather than doing; site manager if you will. This role is distinct from Jonty and Russ as they have their own things to do.<br />
*Maybe find a way to ensure volunteers get some time off? I saw a lot of people who seemed to be always working. I guess that partly shows a need for far more casual volunteers, but perhaps also that some of the more technical jobs might need training-in for earlier? Also, there could be a need for more willingness to delegate occasionally? -[[User:Dermot|Dermot]]<br />
<br />
==Suggestions==<br />
* Ask for an optional email address for each ticket to go on your announce only mailing list. Only the person that bought the tickets got your emails and they were slow to forward them on meaning most messages were received too late.<br />
* Ask for age of children when booking, to give better planning stats for workshops etc. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* A talk (a bit like lightning talks) where people are given 5-10 minutes to share what they did with the previous event's badge. (If someone sends me the competition winners/runners up, I'll co-ordinate it) [[User:MatS|MatS]] ([[User talk:MatS|talk]]) 07:54, 1 September 2014 (UTC)<br />
* Pre-paid accounts for spending money on food/beer/whatever to negate need for cash ([[User:Markp]])<br />
* Have a fleet of communal wheel-barrows to help people transport their stuff from car to campsite [+2]<br />
** Stepney City Farm have a fleet of broken wheelbarrows – fix ’em, use ’em, everybody wins! ([[User:Andylolz]])<br />
** Or purchase some sack trolleys<br />
* contactless payment gear for food, beer, workshops<br />
** We had contactless payment for beer! (And we also offered cashback.) We should have messaged that better. Contactless payment for other things is complex, as we don't really control them. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
* forewarn food vendors to expect all-day demand, not just mealtimes, so they can stock and staff appropriately [+1]<br />
** food vendors were pretty much *events* caterers, used to feeding people snacks/lunch, we need *festival* caterers who are used to feeding people who are staying for a number of days. thethalicafe.co.uk? bedouin tent (shambala)? +late night options [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
*** It's really difficult to get caterers. Now we're a bit better known it's getting easier. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
* pinboard (offline) notice board everyone can contribute to (lost property, mini event notices eg rocket launches, would like to meet.., etc) [+1]<br />
** This was supposed to be next to the info tent, but got lost in the last-minute panic. --[[User:Jonty|Jonty]]<br />
* Ask people who want to give workshops if they'd be happy to give more than one session - the blacksmiths' output was extreme, but even giving two or three sessions would greatly increase the % of attendees who could sign up.<br />
** Many workshop submissions specified that already, the issue was actually with finding space for them as we only had one workshop tent. We'll have many next time! --[[User:Jonty|Jonty]]<br />
* Sign-ups some kind of "express preference" systems, so most people (including those who don't check email regularly) can get at least one of their top choices, rather than first-come-first-served.<br />
** Online workshop sign-up is a priority for next year. --[[User:Jonty|Jonty]]<br />
* Board games tent in the evenings [+4]<br />
** was the lounge not appropriate? Stages B & C were mostly empty on an evening; would tables have sufficed?<br />
* Poker tent<br />
* Be less ambitious with badge functionality [+3]<br />
** And provide full documentation of features/functionality [+1]<br />
** And sample code for each function<br />
** Perhaps a back-to-basics through-hole design that comes with soldering iron, solder and instructions?<br />
** I think we might build on this design for the next event. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
** Software that doesn't involve an OS (but rather more conventional Arduinoery) might be more easily hackable by others during/after the event? Especially given libraries for people to do amusing things with the peer-to-peer radio...<br />
*** That is actually much harder to build anything decent with. The badges are normal arduinos and all the libraries are available, you don't have to use the EMF OS, it was designed for people to write normal Arduino code for! --[[User:Jonty|Jonty]]<br />
* EMF is unlike other festivals - for a large number of people, carrying kit to/from car is impractical and security walking every car through site is time-consuming and volunteer-intensive (not to mention the fact that cars driving off site weren't walked off). Suggest that the parking area is directly next to and easily accessible from the camping area (e.g. just separated by hay bales to stop cars driving on to the camping area).<br />
** As a village/car user you could generally provide your own security person walking in front of the car. This works 2 fold: 1) security doesn't need to walk for you 2) less waiting time for you since you already provide someone to walk.<br />
** The plan for this was to allow people to drive onto site on the Thursday evening. It wasn't very well communicated and we had a *very* tight setup schedule so we needed to reduce this as much as possible. This is ultimately an issue with our setup schedule<br />
** It wouldn't work on this site, but for some locations it might be possible to have a drop-off point close to camping (with a limited number of cars at one time), better idea than having cars (ignition source) close to tents. Some people were taking the mickey on Monday morning, many people driving onto site that could have carried things instead tying up volunteer resources to escort them.<br />
* Provide job descriptions for traffic control, parking and entrance gatehouse. Instructions were handed from volunteer to volunteer by word of mouth and whilst common sense prevailed, it would have been useful to have instructions as to what to do under certain circumstances and a list of answers to FAQs, e.g.:<br />
** What if somebody didn't have a parking ticket and wanted to park?<br />
** What if somebody was just dropping off - where should they do this?<br />
** What times were shuttle buses running?<br />
** What times the gates were open/closed?<br />
** Have a priority queue for people with machine readable tickets (ie paper!)<br />
** Volunteer training was lost by the wayside for some roles, we'll fix that. --[[User:Jonty|Jonty]]<br />
* Add suggested age ranges for all workshops, some of the "adult" workshops were also very suitable for children (e.g. electronic fashion, solar pv) or could have been run once in main workshop once in kid's area [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
** This was supposed to happen but got missed off by accident. Apologies. --[[User:Jonty|Jonty]]<br />
* Bolt the fence from the right side, I know we didn't even want it at all but local authorities can be fussy, I've been at a festival before who did the same and they made them fix it during the event.. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* Want the good coffee on Monday morning, especially for drivers :) Maybe in the car park to help persuade people off site. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* Would be good to have eggs, fresh milk, bacon at the shop (there was a comment like "we don't have eggs, they break too easily" - so charge extra to cover this, though it's probably not as bad as you think..) [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
** The shop was being run by an external team, we didn't control what they stocked. --[[User:Jonty|Jonty]]<br />
** Morrisons did a tent with Milk, Bread, Burgers, BBQs etc @ http://www.festivalofcycling.org/expo/name/morrisons/, might be worth asking them? [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]])<br />
* Start ticket sales (a couple of months?) earlier, maybe with a slightly bigger difference between early ticket prices and full price to encourage attendees to get in early (which in turn would improve cashflow) [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]]) [+1]<br />
* Start ticket sales *now* whilst you have all the publicity or at least have a page up where people can register to be emailed once the next event has tickets for sale. That way you get your current mailing list + everyone else who has only just learned about it as your audience. [[User:Alteralias|Alteralias]]<br />
** Until we have a date/venue that is not a great plan, as we'd end up with a lot of refunds. --[[User:Jonty|Jonty]]<br />
*** Please let us still register to be emailed as soon as 2016 is confirmed and then told as soon as ticket sales start?<br />
*** Although a massive mailing list/Twitter/Facebook push might be a good idea so people are ready to hear that tickets are on sale.<br />
* Cluster the talks into related-topic sessions<br />
** This is very difficult due to availability of speakers, and we'd rather people with very specific interests had talks to go to all weekend rather than just on one afternoon. --[[User:Jonty|Jonty]]<br />
*** More Q&A sessions like the security one, getting multiple speakers on a topic together for questions might be a better idea.<br />
* Volunteering stuff ([[User:HughePaul|HughePaul]])<br />
** Whiteboard in info tent for current issues / tasks, handover<br />
** Have info tent next to security tent so both can be available at the same time and all the time.<br />
*** The info tent and the gatehouse/security tent could be two sides of the same erection.<br />
** have predefined named people in shifts for head of / coordination of volunteering (could also double as an info/security tent staff)<br />
** maybe stream some talks in info tent so they don't feel like they are missing things<br />
** more formal defined (and communicated) lost-property form and procedure<br />
** define volunteer job roles to make handovers easier and so we know what we are meant to be doing<br />
** Look at ways to guarantee volunteer attendance once they sign up. Perhaps return small monetary amount at end of festival per shift done? Just something to make sure people who sign up turn up<br />
*** Food tokens at the end of the shift are how other events do it and could be good incentive.<br />
* Have dedicated blog / tweet / website updating person/team - dedicated live media team would be great<br />
* big screen with latest official event update tweets<br />
** Very expensive to hire. --[[User:Jonty|Jonty]]<br />
*** small screen with latest updates? even a 20 inch cycling through the latest tweets in a big font?<br />
* info about getting DISconnected from DKs and leaving the site in vehicles<br />
** all vehicles coming into site should have had it explained they needed to come get an escort to leave. this wasn't properly communicated and will be better next year (possibly printed on the camper tickets? --[[User:BuildTheRobots|BuildTheRobots]]<br />
** This was badly handled, and we only realised when it was too late. --[[User:Jonty|Jonty]]<br />
* perhaps worth putting up a summary of the overall budget after the event, so people can see what's costly?<br />
* website needs to be designed around the info people need at the time<br />
** days before the event front page should have location, travel, packing, instructions such as workshop booking, village booking, volunteering<br />
** during it should have info about DKs, current day schedule (possibly whats on and next), links to streams, power and internet usage :), lost property instructions, latest updates/tweets<br />
** after have thanks, photos, tilda sales, etc<br />
* Some kind of welcome tent / meet-a-stranger area / badges saying "talk to me" (and not reliant on tech that might not be available/working till later on) / person-bingo-style game - deliberately flagged up as a way for people to meet new people, including if they came on their own / hadn't been to anything like this before. For many the whole event will be like that anyway - it wouldn't hurt to help out those shyer / newer / more awkward. Maybe there could be a welcoming/newbies/friendliness team prior to next time who came up with stuff to try of this nature (all utterly optional, of course)?<br />
** Gregarious people on site to do welcome/orientation would be great (possibly just after getting your wrist band, as part of handing out welcome packs). Can we encourage people to get talking more in irc/mailing list so they have some people they already know once they arrive?<br />
* More flying cars (requested by someone leaving site when asked what they thought was lacking)<br />
* Dual controls quad-copter training. So someone can learn to fly and know the "instructer" can take over if it gets out of hand.<br />
* A few people with cars were making trips out to the outdoor supplies store in Milton Keynes for camping stuff, might be worth figuring out if we could do a more official shop run to get stuff for people who don't have cars.<br />
* Ability to gauge interest if you're thinking of giving a talk: It turned out lots of people could have given a talk on something interesting, but didn't think anyone else would be interested in hearing it. Something like a pledge page where people can "I could give a talk on x, y or z" and people then convince them to do it.<br />
* Cash machines? Possibly expensive next year might be big enough.<br />
** There was cashback available at the bar, which is much cheaper and easier to set up. Its existence wasn't as well publicised as it could have been. [[User:Sde|Sde]] ([[User talk:Sde|talk]])<br />
* Push button on the side of DKs so people can alert NOC their attendance is wanted.<br />
** Also could request vehicle escort off site. -maybe a bunch of waterproof tweeting arduinos with big buttons. yay - more hardware deadlines!<br />
* Hardwired field-phone to all villages and marquees if only so they can report back and request assistance from control.<br />
* welcome packs handed out when you arrive. Possibly lanyard + laminated map, maybe even a fully printed booklet with info on talks/speakers/workshops and sponsor advertising, the "your closest" from the wiki and (emergency) contact numbers.<br />
** You should have been given an information booklet with map on arrival containing most of this, if you were not, please let us know. It is not feasible to put talk/speaker/workshop information in the booklet as we have 150+ events over the weekend, and they change at short notice. --[[User:Jonty|Jonty]]<br />
* Public power sockets under the seats in the marquees. Means people can charge laptops and phones when watching talks and apparently this is done at other cons.<br />
* Power lockers! Like swimming bath lockers but with an electric socket inside so people can lock stuff up to charge for an hour or so.<br />
** +1 I think Colocker missed a trick here. They could have had secure charging lockers promoting their service :)</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Feedback&diff=3568Feedback2014-09-04T13:47:37Z<p>Jonty: </p>
<hr />
<div>{{link-banner}}<br />
Please let us know what went well and what didn't go well at EMF this year. We really do care about your feedback and we'll try and improve this for next time.<br />
<br />
Add your feedback below:<br />
<br />
== Good Stuff ==<br />
<br />
* Location<br />
* Badges<br />
* Variety of talks [+1]<br />
* Showers [+∞]<br />
* Hand washing facilities<br />
** putting the showers (with hot water in handbasins) next to toilets v.good<br />
* Parking<br />
* Shuttle trailer to car park<br />
** ... and shuttle to BLY railway station. Made coming by public transport a doddle.<br />
* Power & data infrastructure - pretty much rock solid throughout! [+2]<br />
* Speedy response of volunteers/organisers to problem resolution<br />
* Service at the bar was good (while the drinks lasted), and it was very nice to have ''multiple'' indoor social spaces, esp for people who wanted a quieter lounge as well as louder bar.<br />
** Being able to check beer availability on the till website was awesome!<br />
* Floor panel roads [+4]<br />
* String lights (cut through to showers was awesome!) [+1]<br />
* Ability to hire tables/chairs/marquees/hay bales etc. - were all good quality, too. [+1]<br />
* Kids workshops [+1]<br />
* Arcade!<br />
* Friendliness of other attendees<br />
* First aid<br />
* Shop - selling books of speakers was a really nice idea, and it was good to talk to speakers & do signing there afterwards.<br />
* That spinning music installation.<br />
* Lighting - I didn't have to turn my torch on at all, but it was still dark enough in my tent to sleep.<br />
* Club Mate.<br />
* Ring making workshop<br />
* Lake was pretty<br />
* Supportive atmosphere for speakers and very nice feedback afterwards<br />
* Water: plentiful flow, tasty water, cool dispensers [+1]<br />
** Hand soap by taps (udders?)<br />
* Keeping toilet paper supplies topped up in all the toilets<br />
* Nice choice of real ales and proper cider<br />
* Lasershow + Chiptunes in Tent A<br />
* Tschunk<br />
* Everything that Dimitri brought along<br />
* EMF CTF: Like getting lock pickers to cook your food, playing IRL replay,relay and pre-play attacks and memory corruption, sadly no real-life cross-site scripting :)<br />
<br />
== Stuff that could be improved ==<br />
<br />
* Buy more beer! [[User:Russ|Russ]] ([[User talk:Russ|talk]]) [+1]<br />
** No firkins next time, kils only! --[[User:Sde|Sde]] ([[User talk:Sde|talk]])<br />
* Toilets... 'nuff said! [[User:AndyB|AndyB]] ([[User talk:AndyB|talk]]) [+2]<br />
** Agreed - I've seen portakabins (like the shower blocks) that containing proper flushing loos. They're ''much'' less stinky and likely to block up than the portaloos we had, which didn't always seem willing to drop their loads into their collection tanks, leading to nastiness and health hazards (even without the pumping contractor being rubbish)<br />
*** This was actually what we wanted, but they're tremendously expensive. Suggestions for vendors welcome! --[[User:Jonty|Jonty]]<br />
** Additionally, LIGHTS in the toilets. Having to use my phone / badge as a torch to see what was going on while i cleaned off the toilet before sitting down was particularly difficult. [[User:Thinkl33t|Thinkl33t]] ([[User talk:Thinkl33t|talk]]) 20:05, 1 September 2014 (UTC)<br />
** thunderboxes2go.co.uk are good and know how to handle local authority problems, they have done shambala for 10+ years - high enough capacity to not need emptying during the event [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
** Maybe ask Cambridge & District CAMRA who provided the toilets for Cambridge 41st beer festival - they had some fairly nice flushing toilets which came on a trailer, a bit like the posh wash showers. I think Jonty mentioned that a lot of providers were put off by the fact that we're a festival. Well, if these guys are ok with providing for a beer festival, they must be pretty brave! -[[User:Alecjw]]<br />
** Definite vote for the trailer-style flushing toilets, with multiple cubicles (+sinks, lights and mirrors) on one tow-along trailer, just like the showers. I've seen these at MANY festivals - though, granted, usually only in 'posh' camping/press/VIP areas. Should be possible if you manage to convince the providers that we're not a rowdy bunch of drunken teenagers!<br />
** A clue to the problem with the chemical toilets is in the name: no chemical sanitiser/deodoriser was used in any toilet I tried. Adding Elsan or similar to the toilets would probably have made them much more acceptable. [[User:PhilSwinbank|PhilSwinbank]] ([[User talk:PhilSwinbank|talk]]) 22:18, 3 September 2014 (UTC)<br />
* Make sure that drinking water is clearly labelled as such<br />
* More food and drink options<br />
** Eg. non-caffeine / low or no sugar options<br />
** Chips!<br />
** Jacket potato vendor<br />
** Healthy 'green' food<br />
** also possibly going on later, a lot of the places shut up shop quite early.<br />
** A late night vendor would be fantastic - doesn't have to be fancy food, but just something hot to eat after 9pm [+2]<br />
* Survey positions of lanes/tents/DKs as early as possible before items arrive and mark out.--[[User:Sully|Sully]] ([[User talk:Sully|talk]]) 12:06, 1 September 2014 (UTC)<br />
** This was planned but we were let down by the rather poor state of mobile GIS software. <br />
*** there are multiple open source solutions for mapping, try https://umap.openstreetmap.fr/en/ or reach to out myself or #openstreetmap, there are many OSM'ers in the UK, [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]]).<br />
* Similar to this, measure for fence panels and drop stillage appropriately, to avoid the need to carry loads of them right up the camping field by hand<br />
* Make it longer! There was loads of cool stuff I didn't have change to check out :( After all that work everyone does, it was a shame I couldn't experience it all! ([[User:Chewie|Chewie]])<br />
* Visibility of presentations in tents (brighter projectors/darker tents??) ([[User:StuartL]]) [+2]<br />
** Next time dark tents. This was a total nightmare, sorry. --[[User:Jonty|Jonty]]<br />
* washing points over drains/soakaway so the ground doesn't get muddy ([[User:Chewie|Chewie]]) [+3]<br />
* Mark out/allocate spaces for villages who had pinpointed locations on maps ([[User:Markp]]) [+1]<br />
* Use more plasma screens in stages instead of projectors ([[User:Markp]]). Or (better, as then the speaker can point to things) black fabric shades for the screen or marquee roof<br />
* Improved arrangements for washing and washing up (and handling the waste water from that) [+1]<br />
* Provide sanitizer gel dispensers at water points and near loos [+1]<br />
* Have the schedule linked off the EMF main page<br />
** It was, but not on the First day...we forgot! See "Programme" at the top of the main website. --[[User:Jonty|Jonty]]<br />
* Distribute and display paper schedules (even if their might be some last-minute changes) [+2]<br />
** They were supposed to be available at the info tent, not sure what happened there. --[[User:Jonty|Jonty]]<br />
** Or have small screens at the entrances to tents showing what's currently on & what's next.<br />
*** We wanted to do this but simply ran out of time. --[[User:Jonty|Jonty]]<br />
* Much more workshop activity (more hands-on electronics and physical making) [+5]<br />
** Next time: Many more workshop tents. We totally underestimated availability and demand. --[[User:Jonty|Jonty]]<br />
* Do have component vendors (maybe at their cost for marquee/power/space)<br />
** This is very difficult without a clear list of what will sell, as CPC was arranged to appear but wanted advisement ([[User:Stanto]])<br />
* Pick a flatter site (for ease of disabled access)<br />
* Ask speakers for bio's to include with their abstracts. Given them an abstract length up-front instead of editing it in an ad hoc way. Confirm acceptance to speakers and workshop organisers earlier.<br />
** Do this after talks have been accepted. I didn't write my talk so didn't know details until I got the OK.<br />
** The CFP was a bit of a nightmare this year, we'll certainly be doing this in 2016. --[[User:Jonty|Jonty]]<br />
* Make and enforce a clear music curfew (say from midnight or 1am or 2am to 8 or 9am or 10am), to defend those sleeping from (eg) the technoevangelists and the drunk [+4]<br />
** Perhaps try to select a site next time where we can make part of the site to be a quiet area, eg a part surrounded by trees for natural sound insulation. Then enforce a noise curfew there. I'm not keen on the idea of having a noise curfew covering the entire camp though. [[User:Alecjw]] [+1]<br />
** Seconding enforced quiet/family camping area, but no overall noise curfew. It didn't take long to get away from the worst noise, and the end of the field by the kids' area was incredibly quiet (though strangely empty!!)<br />
* Loos not so near food vendors (pong + visible urinals offputting) [+5]<br />
* stronger enforcement/signage of quiet camping area [+4]<br />
* an explicit invitation (with clear instructions) to report Code of Conduct violations in open ceremony, brochure, Twitter, etc. We had no direct reports to Team Comfort, but several anecdotal tweets after the event -- when it's much too late. [[User:Martind|Martind]] ([[User talk:Martind|talk]]) 20:58, 1 September 2014 (UTC) [+1]<br />
* quieter, less-enclosed and more spacious bar (I suffer from social anxiety when I'm closed in with crowds, so I had a very sober emf!). [[User:Jane C|Jane C]]<br />
** perhaps an outdoor seating area if a larger marquee is too costly.<br />
*** There was an outdoor seating area set back to the right of the bar under a marquee, however the marquee vendor put it in the wrong place a day late, so wasn't as obvious, and didn't get hay bales until Saturday evening. --[[User:Jonty|Jonty]]<br />
* use our collective knowledge of technology to sort accessibility issues <br />
**ring-fence money for things like closed-loop in the stages early on. <br />
**ask people about their access requirements much earlier on - e.g. when they buy a ticket - so that there is more time to meet these requirements (or reach a workable compromise)<br />
**Build some kind of working system for preventing able-bodied people from using the disabled loos and showers (radar keys that only work when the loo is empty?) [[User:Jane C|Jane C]]<br />
* Info desk didn't seem to have the details wrt. volunteers, so when I volunteered I was sent out and found I wasn't needed. Suggest splitting the job - having a volunteer team leader (or several, in shifts) whose job it is to know who is where and also to make sure nobody gets stuck on a gate for 12 hours (eg. rotating people to more interesting places every couple of hours). ([[User:TonyHoyle|TonyHoyle]])<br />
** There was a separate volunteer manager in the same tent, this should not have happened. Sorry about that. --[[User:Jonty|Jonty]]<br />
* Also similar to this, a register of 'on call' people - excess volunteers who can deal with sudden demands for people (esp. in the case of fire I can imagine this would be extremely useful - you'd potentially need to cordon off a largish area very quickly, and that takes people. More mundane reasons would be a talk/workshop accumulating a large queue that needs managing). ([[User:TonyHoyle|TonyHoyle]])<br />
** There were shifts for people to be "on call" but they weren't obvious. We'll make sure this is easier. --[[User:Jonty|Jonty]]<br />
* add GPS or other location aware technology like BTLE/iBeacon to the badges for automatic now/next notifications [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]]).<br />
<br />
==Suggestions==<br />
* Ask for an optional email address for each ticket to go on your announce only mailing list. Only the person that bought the tickets got your emails and they were slow to forward them on meaning most messages were received too late.<br />
* Ask for age of children when booking, to give better planning stats for workshops etc. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* A talk (a bit like lightning talks) where people are given 5-10 minutes to share what they did with the previous event's badge. (If someone sends me the competition winners/runners up, I'll co-ordinate it) [[User:MatS|MatS]] ([[User talk:MatS|talk]]) 07:54, 1 September 2014 (UTC)<br />
* Pre-paid accounts for spending money on food/beer/whatever to negate need for cash ([[User:Markp]])<br />
* Have a fleet of communal wheel-barrows to help people transport their stuff from car to campsite [+1]<br />
** Stepney City Farm have a fleet of broken wheelbarrows – fix ’em, use ’em, everybody wins! ([[User:Andylolz]])<br />
** Or purchase some sack trolleys<br />
* contactless payment gear for food, beer, workshops<br />
** We had contactless payment for beer! (And we also offered cashback.) We should have messaged that better. Contactless payment for other things is complex, as we don't really control them. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
* forewarn food vendors to expect all-day demand, not just mealtimes, so they can stock and staff appropriately [+1]<br />
** food vendors were pretty much *events* caterers, used to feeding people snacks/lunch, we need *festival* caterers who are used to feeding people who are staying for a number of days. thethalicafe.co.uk? bedouin tent (shambala)? +late night options [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
*** It's really difficult to get caterers. Now we're a bit better known it's getting easier. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
* pinboard (offline) notice board everyone can contribute to (lost property, mini event notices eg rocket launches, would like to meet.., etc) [+1]<br />
** This was supposed to be next to the info tent, but got lost in the last-minute panic. --[[User:Jonty|Jonty]]<br />
* Ask people who want to give workshops if they'd be happy to give more than one session - the blacksmiths' output was extreme, but even giving two or three sessions would greatly increase the % of attendees who could sign up.<br />
** Many workshop submissions specified that already, the issue was actually with finding space for them as we only had one workshop tent. We'll have many next time! --[[User:Jonty|Jonty]]<br />
* Sign-ups some kind of "express preference" systems, so most people (including those who don't check email regularly) can get at least one of their top choices, rather than first-come-first-served.<br />
** Online workshop sign-up is a priority for next year. --[[User:Jonty|Jonty]]<br />
* Board games tent in the evenings [+4]<br />
* Poker tent<br />
* Be less ambitious with badge functionality [+3]<br />
** And provide full documentation of features/functionality [+1]<br />
** And sample code for each function<br />
** Perhaps a back-to-basics through-hole design that comes with soldering iron, solder and instructions?<br />
** I think we might build on this design for the next event. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
** Software that doesn't involve an OS (but rather more conventional Arduinoery) might be more easily hackable by others during/after the event? Especially given libraries for people to do amusing things with the peer-to-peer radio...<br />
*** That is actually much harder to build anything decent with. The badges are normal arduinos and all the libraries are available, you don't have to use the EMF OS, it was designed for people to write normal Arduino code for! --[[User:Jonty|Jonty]]<br />
* EMF is unlike other festivals - for a large number of people, carrying kit to/from car is impractical and security walking every car through site is time-consuming and volunteer-intensive (not to mention the fact that cars driving off site weren't walked off). Suggest that the parking area is directly next to and easily accessible from the camping area (e.g. just separated by hay bales to stop cars driving on to the camping area).<br />
** As a village/car user you could generally provide your own security person walking in front of the car. This works 2 fold: 1) security doesn't need to walk for you 2) less waiting time for you since you already provide someone to walk.<br />
** The plan for this was to allow people to drive onto site on the Thursday evening. It wasn't very well communicated and we had a *very* tight setup schedule so we needed to reduce this as much as possible. This is ultimately an issue with our setup schedule<br />
** It wouldn't work on this site, but for some locations it might be possible to have a drop-off point close to camping (with a limited number of cars at one time), better idea than having cars (ignition source) close to tents. Some people were taking the mickey on Monday morning, many people driving onto site that could have carried things instead tying up volunteer resources to escort them.<br />
* Provide job descriptions for traffic control, parking and entrance gatehouse. Instructions were handed from volunteer to volunteer by word of mouth and whilst common sense prevailed, it would have been useful to have instructions as to what to do under certain circumstances and a list of answers to FAQs, e.g.:<br />
** What if somebody didn't have a parking ticket and wanted to park?<br />
** What if somebody was just dropping off - where should they do this?<br />
** What times were shuttle buses running?<br />
** What times the gates were open/closed?<br />
** Have a priority queue for people with machine readable tickets (ie paper!)<br />
** Volunteer training was lost by the wayside for some roles, we'll fix that. --[[User:Jonty|Jonty]]<br />
* Add suggested age ranges for all workshops, some of the "adult" workshops were also very suitable for children (e.g. electronic fashion, solar pv) or could have been run once in main workshop once in kid's area [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
** This was supposed to happen but got missed off by accident. Apologies. --[[User:Jonty|Jonty]]<br />
* Bolt the fence from the right side, I know we didn't even want it at all but local authorities can be fussy, I've been at a festival before who did the same and they made them fix it during the event.. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* Want the good coffee on Monday morning, especially for drivers :) Maybe in the car park to help persuade people off site. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* Would be good to have eggs, fresh milk, bacon at the shop (there was a comment like "we don't have eggs, they break too easily" - so charge extra to cover this, though it's probably not as bad as you think..) [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
** The shop was being run by an external team, we didn't control what they stocked. --[[User:Jonty|Jonty]]<br />
** Morrisons did a tent with Milk, Bread, Burgers, BBQs etc @ http://www.festivalofcycling.org/expo/name/morrisons/, might be worth asking them? [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]])<br />
* Start ticket sales (a couple of months?) earlier, maybe with a slightly bigger difference between early ticket prices and full price to encourage attendees to get in early (which in turn would improve cashflow) [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]]) [+1]<br />
* Start ticket sales *now* whilst you have all the publicity or at least have a page up where people can register to be emailed once the next event has tickets for sale. That way you get your current mailing list + everyone else who has only just learned about it as your audience. [[User:Alteralias|Alteralias]]<br />
** Until we have a date/venue that is not a great plan, as we'd end up with a lot of refunds. --[[User:Jonty|Jonty]]<br />
* Cluster the talks into related-topic sessions<br />
** This is very difficult due to availability of speakers, and we'd rather people with very specific interests had talks to go to all weekend rather than just on one afternoon. --[[User:Jonty|Jonty]]<br />
* Volunteering stuff ([[User:HughePaul|HughePaul]])<br />
** Whiteboard in info tent for current issues / tasks, handover<br />
** Have info tent next to security tent so both can be available at the same time and all the time.<br />
*** The info tent and the gatehouse/security tent could be two sides of the same erection.<br />
** have predefined named people in shifts for head of / coordination of volunteering (could also double as an info/security tent staff)<br />
** maybe stream some talks in info tent so they don't feel like they are missing things<br />
** more formal defined (and communicated) lost-property form and procedure<br />
** define volunteer job roles to make handovers easier and so we know what we are meant to be doing<br />
* Have dedicated blog / tweet / website updating person/team<br />
* big screen with latest official event update tweets<br />
** Very expensive to hire. --[[User:Jonty|Jonty]]<br />
* info about getting DISconnected from DKs and leaving the site in vehicles<br />
** This was badly handled, and we only realised when it was too late. --[[User:Jonty|Jonty]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Feedback&diff=3566Feedback2014-09-04T13:30:53Z<p>Jonty: </p>
<hr />
<div>{{link-banner}}<br />
Please let us know what went well and what didn't go well at EMF this year. We really do care about your feedback and we'll try and improve this for next time.<br />
<br />
Add your feedback below:<br />
<br />
== Good Stuff ==<br />
<br />
* Location<br />
* Badges<br />
* Variety of talks [+1]<br />
* Showers [+∞]<br />
* Hand washing facilities<br />
** putting the showers (with hot water in handbasins) next to toilets v.good<br />
* Parking<br />
* Shuttle trailer to car park<br />
** ... and shuttle to BLY railway station. Made coming by public transport a doddle.<br />
* Power & data infrastructure - pretty much rock solid throughout! [+2]<br />
* Speedy response of volunteers/organisers to problem resolution<br />
* Service at the bar was good (while the drinks lasted), and it was very nice to have ''multiple'' indoor social spaces, esp for people who wanted a quieter lounge as well as louder bar.<br />
** Being able to check beer availability on the till website was awesome!<br />
* Floor panel roads [+4]<br />
* String lights (cut through to showers was awesome!) [+1]<br />
* Ability to hire tables/chairs/marquees/hay bales etc. - were all good quality, too. [+1]<br />
* Kids workshops [+1]<br />
* Arcade!<br />
* Friendliness of other attendees<br />
* First aid<br />
* Shop - selling books of speakers was a really nice idea, and it was good to talk to speakers & do signing there afterwards.<br />
* That spinning music installation.<br />
* Lighting - I didn't have to turn my torch on at all, but it was still dark enough in my tent to sleep.<br />
* Club Mate.<br />
* Ring making workshop<br />
* Lake was pretty<br />
* Supportive atmosphere for speakers and very nice feedback afterwards<br />
* Water: plentiful flow, tasty water, cool dispensers [+1]<br />
** Hand soap by taps (udders?)<br />
* Keeping toilet paper supplies topped up in all the toilets<br />
* Nice choice of real ales and proper cider<br />
* Lasershow + Chiptunes in Tent A<br />
* Tschunk<br />
* Everything that Dimitri brought along<br />
* EMF CTF: Like getting lock pickers to cook your food, playing IRL replay,relay and pre-play attacks and memory corruption, sadly no real-life cross-site scripting :)<br />
<br />
== Stuff that could be improved ==<br />
<br />
* Buy more beer! [[User:Russ|Russ]] ([[User talk:Russ|talk]]) [+1]<br />
** No firkins next time, kils only! --[[User:Sde|Sde]] ([[User talk:Sde|talk]])<br />
* Toilets... 'nuff said! [[User:AndyB|AndyB]] ([[User talk:AndyB|talk]]) [+2]<br />
** Agreed - I've seen portakabins (like the shower blocks) that containing proper flushing loos. They're ''much'' less stinky and likely to block up than the portaloos we had, which didn't always seem willing to drop their loads into their collection tanks, leading to nastiness and health hazards (even without the pumping contractor being rubbish)<br />
*** This was actually what we wanted, but they're tremendously expensive. Suggestions for vendors welcome!<br />
** Additionally, LIGHTS in the toilets. Having to use my phone / badge as a torch to see what was going on while i cleaned off the toilet before sitting down was particularly difficult. [[User:Thinkl33t|Thinkl33t]] ([[User talk:Thinkl33t|talk]]) 20:05, 1 September 2014 (UTC)<br />
** thunderboxes2go.co.uk are good and know how to handle local authority problems, they have done shambala for 10+ years - high enough capacity to not need emptying during the event [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
** Maybe ask Cambridge & District CAMRA who provided the toilets for Cambridge 41st beer festival - they had some fairly nice flushing toilets which came on a trailer, a bit like the posh wash showers. I think Jonty mentioned that a lot of providers were put off by the fact that we're a festival. Well, if these guys are ok with providing for a beer festival, they must be pretty brave! -[[User:Alecjw]]<br />
** Definite vote for the trailer-style flushing toilets, with multiple cubicles (+sinks, lights and mirrors) on one tow-along trailer, just like the showers. I've seen these at MANY festivals - though, granted, usually only in 'posh' camping/press/VIP areas. Should be possible if you manage to convince the providers that we're not a rowdy bunch of drunken teenagers!<br />
** A clue to the problem with the chemical toilets is in the name: no chemical sanitiser/deodoriser was used in any toilet I tried. Adding Elsan or similar to the toilets would probably have made them much more acceptable. [[User:PhilSwinbank|PhilSwinbank]] ([[User talk:PhilSwinbank|talk]]) 22:18, 3 September 2014 (UTC)<br />
* Make sure that drinking water is clearly labelled as such<br />
* More food and drink options<br />
** Eg. non-caffeine / low or no sugar options<br />
** Chips!<br />
** Jacket potato vendor<br />
** Healthy 'green' food<br />
** also possibly going on later, a lot of the places shut up shop quite early.<br />
** A late night vendor would be fantastic - doesn't have to be fancy food, but just something hot to eat after 9pm [+2]<br />
* Survey positions of lanes/tents/DKs as early as possible before items arrive and mark out.--[[User:Sully|Sully]] ([[User talk:Sully|talk]]) 12:06, 1 September 2014 (UTC)<br />
** This was planned but we were let down by the rather poor state of mobile GIS software. <br />
*** there are multiple open source solutions for mapping, try https://umap.openstreetmap.fr/en/ or reach to out myself or #openstreetmap, there are many OSM'ers in the UK, [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]]).<br />
* Similar to this, measure for fence panels and drop stillage appropriately, to avoid the need to carry loads of them right up the camping field by hand<br />
* Make it longer! There was loads of cool stuff I didn't have change to check out :( After all that work everyone does, it was a shame I couldn't experience it all! ([[User:Chewie|Chewie]])<br />
* Visibility of presentations in tents (brighter projectors/darker tents??) ([[User:StuartL]]) [+2]<br />
* washing points over drains/soakaway so the ground doesn't get muddy ([[User:Chewie|Chewie]]) [+3]<br />
* Mark out/allocate spaces for villages who had pinpointed locations on maps ([[User:Markp]]) [+1]<br />
* Use more plasma screens in stages instead of projectors ([[User:Markp]]). Or (better, as then the speaker can point to things) black fabric shades for the screen or marquee roof<br />
* Improved arrangements for washing and washing up (and handling the waste water from that) [+1]<br />
* Provide sanitizer gel dispensers at water points and near loos [+1]<br />
* Have the schedule linked off the EMF main page<br />
** It was, but not on the First day...we forgot! See "Programme" at the top of the main website.<br />
* Distribute and display paper schedules (even if their might be some last-minute changes) [+2]<br />
** Or have small screens at the entrances to tents showing what's currently on & what's next.<br />
* Much more workshop activity (more hands-on electronics and physical making) [+5]<br />
* Do have component vendors (maybe at their cost for marquee/power/space)<br />
** This is very difficult without a clear list of what will sell, as CPC was arranged to appear but wanted advisement ([[User:Stanto]])<br />
* Pick a flatter site (for ease of disabled access)<br />
* Ask speakers for bio's to include with their abstracts. Given them an abstract length up-front instead of editing it in an ad hoc way. Confirm acceptance to speakers and workshop organisers earlier.<br />
** Do this after talks have been accepted. I didn't write my talk so didn't know details until I got the OK.<br />
* Make and enforce a clear music curfew (say from midnight or 1am or 2am to 8 or 9am or 10am), to defend those sleeping from (eg) the technoevangelists and the drunk [+4]<br />
** Perhaps try to select a site next time where we can make part of the site to be a quiet area, eg a part surrounded by trees for natural sound insulation. Then enforce a noise curfew there. I'm not keen on the idea of having a noise curfew covering the entire camp though. [[User:Alecjw]] [+1]<br />
** Seconding enforced quiet/family camping area, but no overall noise curfew. It didn't take long to get away from the worst noise, and the end of the field by the kids' area was incredibly quiet (though strangely empty!!)<br />
* Loos not so near food vendors (pong + visible urinals offputting) [+5]<br />
* stronger enforcement/signage of quiet camping area [+4]<br />
* an explicit invitation (with clear instructions) to report Code of Conduct violations in open ceremony, brochure, Twitter, etc. We had no direct reports to Team Comfort, but several anecdotal tweets after the event -- when it's much too late. [[User:Martind|Martind]] ([[User talk:Martind|talk]]) 20:58, 1 September 2014 (UTC) [+1]<br />
* quieter, less-enclosed and more spacious bar (I suffer from social anxiety when I'm closed in with crowds, so I had a very sober emf!). [[User:Jane C|Jane C]]<br />
** perhaps an outdoor seating area if a larger marquee is too costly.<br />
* use our collective knowledge of technology to sort accessibility issues <br />
**ring-fence money for things like closed-loop in the stages early on. <br />
**ask people about their access requirements much earlier on - e.g. when they buy a ticket - so that there is more time to meet these requirements (or reach a workable compromise)<br />
**Build some kind of working system for preventing able-bodied people from using the disabled loos and showers (radar keys that only work when the loo is empty?) [[User:Jane C|Jane C]]<br />
* Info desk didn't seem to have the details wrt. volunteers, so when I volunteered I was sent out and found I wasn't needed. Suggest splitting the job - having a volunteer team leader (or several, in shifts) whose job it is to know who is where and also to make sure nobody gets stuck on a gate for 12 hours (eg. rotating people to more interesting places every couple of hours). ([[User:TonyHoyle|TonyHoyle]])<br />
* Also similar to this, a register of 'on call' people - excess volunteers who can deal with sudden demands for people (esp. in the case of fire I can imagine this would be extremely useful - you'd potentially need to cordon off a largish area very quickly, and that takes people. More mundane reasons would be a talk/workshop accumulating a large queue that needs managing). ([[User:TonyHoyle|TonyHoyle]])<br />
* add GPS or other location aware technology like BTLE/iBeacon to the badges for automatic now/next notifications [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]]).<br />
<br />
==Suggestions==<br />
* Ask for an optional email address for each ticket to go on your announce only mailing list. Only the person that bought the tickets got your emails and they were slow to forward them on meaning most messages were received too late.<br />
* Ask for age of children when booking, to give better planning stats for workshops etc. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* A talk (a bit like lightning talks) where people are given 5-10 minutes to share what they did with the previous event's badge. (If someone sends me the competition winners/runners up, I'll co-ordinate it) [[User:MatS|MatS]] ([[User talk:MatS|talk]]) 07:54, 1 September 2014 (UTC)<br />
* Pre-paid accounts for spending money on food/beer/whatever to negate need for cash ([[User:Markp]])<br />
* Have a fleet of communal wheel-barrows to help people transport their stuff from car to campsite [+1]<br />
** Stepney City Farm have a fleet of broken wheelbarrows – fix ’em, use ’em, everybody wins! ([[User:Andylolz]])<br />
** Or purchase some sack trolleys<br />
* contactless payment gear for food, beer, workshops<br />
** We had contactless payment for beer! (And we also offered cashback.) We should have messaged that better. Contactless payment for other things is complex, as we don't really control them. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
* forewarn food vendors to expect all-day demand, not just mealtimes, so they can stock and staff appropriately [+1]<br />
** food vendors were pretty much *events* caterers, used to feeding people snacks/lunch, we need *festival* caterers who are used to feeding people who are staying for a number of days. thethalicafe.co.uk? bedouin tent (shambala)? +late night options [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
*** It's really difficult to get caterers. Now we're a bit better known it's getting easier. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
* pinboard (offline) notice board everyone can contribute to (lost property, mini event notices eg rocket launches, would like to meet.., etc) [+1]<br />
* Ask people who want to give workshops if they'd be happy to give more than one session - the blacksmiths' output was extreme, but even giving two or three sessions would greatly increase the % of attendees who could sign up.<br />
* Sign-ups some kind of "express preference" systems, so most people (including those who don't check email regularly) can get at least one of their top choices, rather than first-come-first-served.<br />
* Board games tent in the evenings [+4]<br />
* Poker tent<br />
* Be less ambitious with badge functionality [+3]<br />
** And provide full documentation of features/functionality [+1]<br />
** And sample code for each function<br />
** Perhaps a back-to-basics through-hole design that comes with soldering iron, solder and instructions?<br />
** I think we might build on this design for the next event. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
** Software that doesn't involve an OS (but rather more conventional Arduinoery) might be more easily hackable by others during/after the event? Especially given libraries for people to do amusing things with the peer-to-peer radio...<br />
* EMF is unlike other festivals - for a large number of people, carrying kit to/from car is impractical and security walking every car through site is time-consuming and volunteer-intensive (not to mention the fact that cars driving off site weren't walked off). Suggest that the parking area is directly next to and easily accessible from the camping area (e.g. just separated by hay bales to stop cars driving on to the camping area).<br />
** As a village/car user you could generally provide your own security person walking in front of the car. This works 2 fold: 1) security doesn't need to walk for you 2) less waiting time for you since you already provide someone to walk.<br />
** The plan for this was to allow people to drive onto site on the Thursday evening. It wasn't very well communicated and we had a *very* tight setup schedule so we needed to reduce this as much as possible. This is ultimately an issue with our setup schedule<br />
** It wouldn't work on this site, but for some locations it might be possible to have a drop-off point close to camping (with a limited number of cars at one time), better idea than having cars (ignition source) close to tents. Some people were taking the mickey on Monday morning, many people driving onto site that could have carried things instead tying up volunteer resources to escort them.<br />
* Provide job descriptions for traffic control, parking and entrance gatehouse. Instructions were handed from volunteer to volunteer by word of mouth and whilst common sense prevailed, it would have been useful to have instructions as to what to do under certain circumstances and a list of answers to FAQs, e.g.:<br />
** What if somebody didn't have a parking ticket and wanted to park?<br />
** What if somebody was just dropping off - where should they do this?<br />
** What times were shuttle buses running?<br />
** What times the gates were open/closed?<br />
** Have a priority queue for people with machine readable tickets (ie paper!)<br />
* Add suggested age ranges for all workshops, some of the "adult" workshops were also very suitable for children (e.g. electronic fashion, solar pv) or could have been run once in main workshop once in kid's area [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* Bolt the fence from the right side, I know we didn't even want it at all but local authorities can be fussy, I've been at a festival before who did the same and they made them fix it during the event.. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* Want the good coffee on Monday morning, especially for drivers :) Maybe in the car park to help persuade people off site. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* Would be good to have eggs, fresh milk, bacon at the shop (there was a comment like "we don't have eggs, they break too easily" - so charge extra to cover this, though it's probably not as bad as you think..) [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
** Morrisons did a tent with Milk, Bread, Burgers, BBQs etc @ http://www.festivalofcycling.org/expo/name/morrisons/, might be worth asking them? [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]])<br />
* Start ticket sales (a couple of months?) earlier, maybe with a slightly bigger difference between early ticket prices and full price to encourage attendees to get in early (which in turn would improve cashflow) [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]]) [+1]<br />
* Start ticket sales *now* whilst you have all the publicity or at least have a page up where people can register to be emailed once the next event has tickets for sale. That way you get your current mailing list + everyone else who has only just learned about it as your audience. [[User:Alteralias|Alteralias]]<br />
* Cluster the talks into related-topic sessions<br />
* Volunteering stuff ([[User:HughePaul|HughePaul]])<br />
** Whiteboard in info tent for current issues / tasks, handover<br />
** Have info tent next to security tent so both can be available at the same time and all the time.<br />
*** The info tent and the gatehouse/security tent could be two sides of the same erection.<br />
** have predefined named people in shifts for head of / coordination of volunteering (could also double as an info/security tent staff)<br />
** maybe stream some talks in info tent so they don't feel like they are missing things<br />
** more formal defined (and communicated) lost-property form and procedure<br />
** define volunteer job roles to make handovers easier and so we know what we are meant to be doing<br />
* Have dedicated blog / tweet / website updating person/team<br />
* big screen with latest official event update tweets<br />
* info about getting DISconnected from DKs and leaving the site in vehicles</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Feedback&diff=3565Feedback2014-09-04T13:29:38Z<p>Jonty: /* Stuff that could be improved */</p>
<hr />
<div>{{link-banner}}<br />
Please let us know what went well and what didn't go well at EMF this year. We really do care about your feedback and we'll try and improve this for next time.<br />
<br />
Add your feedback below:<br />
<br />
== Good Stuff ==<br />
<br />
* Location<br />
* Badges<br />
* Variety of talks [+1]<br />
* Showers [+∞]<br />
* Hand washing facilities<br />
** putting the showers (with hot water in handbasins) next to toilets v.good<br />
* Parking<br />
* Shuttle trailer to car park<br />
** ... and shuttle to BLY railway station. Made coming by public transport a doddle.<br />
* Power & data infrastructure - pretty much rock solid throughout! [+2]<br />
* Speedy response of volunteers/organisers to problem resolution<br />
* Service at the bar was good (while the drinks lasted), and it was very nice to have ''multiple'' indoor social spaces, esp for people who wanted a quieter lounge as well as louder bar.<br />
** Being able to check beer availability on the till website was awesome!<br />
* Floor panel roads [+4]<br />
* String lights (cut through to showers was awesome!) [+1]<br />
* Ability to hire tables/chairs/marquees/hay bales etc. - were all good quality, too. [+1]<br />
* Kids workshops [+1]<br />
* Arcade!<br />
* Friendliness of other attendees<br />
* First aid<br />
* Shop - selling books of speakers was a really nice idea, and it was good to talk to speakers & do signing there afterwards.<br />
* That spinning music installation.<br />
* Lighting - I didn't have to turn my torch on at all, but it was still dark enough in my tent to sleep.<br />
* Club Mate.<br />
* Ring making workshop<br />
* Lake was pretty<br />
* Supportive atmosphere for speakers and very nice feedback afterwards<br />
* Water: plentiful flow, tasty water, cool dispensers [+1]<br />
** Hand soap by taps (udders?)<br />
* Keeping toilet paper supplies topped up in all the toilets<br />
* Nice choice of real ales and proper cider<br />
* Lasershow + Chiptunes in Tent A<br />
* Tschunk<br />
* Everything that Dimitri brought along<br />
* EMF CTF: Like getting lock pickers to cook your food, playing IRL replay,relay and pre-play attacks and memory corruption, sadly no real-life cross-site scripting :)<br />
<br />
== Stuff that could be improved ==<br />
<br />
* Buy more beer! [[User:Russ|Russ]] ([[User talk:Russ|talk]]) [+1]<br />
** No firkins next time, kils only! --[[User:Sde|Sde]] ([[User talk:Sde|talk]])<br />
* Toilets... 'nuff said! [[User:AndyB|AndyB]] ([[User talk:AndyB|talk]]) [+2]<br />
** Agreed - I've seen portakabins (like the shower blocks) that containing proper flushing loos. They're ''much'' less stinky and likely to block up than the portaloos we had, which didn't always seem willing to drop their loads into their collection tanks, leading to nastiness and health hazards (even without the pumping contractor being rubbish)<br />
*** This was actually what we wanted, but they're tremendously expensive. Suggestions for vendors welcome!<br />
** Additionally, LIGHTS in the toilets. Having to use my phone / badge as a torch to see what was going on while i cleaned off the toilet before sitting down was particularly difficult. [[User:Thinkl33t|Thinkl33t]] ([[User talk:Thinkl33t|talk]]) 20:05, 1 September 2014 (UTC)<br />
** thunderboxes2go.co.uk are good and know how to handle local authority problems, they have done shambala for 10+ years - high enough capacity to not need emptying during the event [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
** Maybe ask Cambridge & District CAMRA who provided the toilets for Cambridge 41st beer festival - they had some fairly nice flushing toilets which came on a trailer, a bit like the posh wash showers. I think Jonty mentioned that a lot of providers were put off by the fact that we're a festival. Well, if these guys are ok with providing for a beer festival, they must be pretty brave! -[[User:Alecjw]]<br />
** Definite vote for the trailer-style flushing toilets, with multiple cubicles (+sinks, lights and mirrors) on one tow-along trailer, just like the showers. I've seen these at MANY festivals - though, granted, usually only in 'posh' camping/press/VIP areas. Should be possible if you manage to convince the providers that we're not a rowdy bunch of drunken teenagers!<br />
** A clue to the problem with the chemical toilets is in the name: no chemical sanitiser/deodoriser was used in any toilet I tried. Adding Elsan or similar to the toilets would probably have made them much more acceptable. [[User:PhilSwinbank|PhilSwinbank]] ([[User talk:PhilSwinbank|talk]]) 22:18, 3 September 2014 (UTC)<br />
* Make sure that drinking water is clearly labelled as such<br />
* More food and drink options<br />
** Eg. non-caffeine / low or no sugar options<br />
** Chips!<br />
** Jacket potato vendor<br />
** Healthy 'green' food<br />
** also possibly going on later, a lot of the places shut up shop quite early.<br />
** A late night vendor would be fantastic - doesn't have to be fancy food, but just something hot to eat after 9pm [+2]<br />
* Survey positions of lanes/tents/DKs as early as possible before items arrive and mark out.--[[User:Sully|Sully]] ([[User talk:Sully|talk]]) 12:06, 1 September 2014 (UTC)<br />
** This was planned but we were let down by the rather poor state of mobile GIS software. <br />
*** there are multiple open source solutions for mapping, try https://umap.openstreetmap.fr/en/ or reach to out myself or #openstreetmap, there are many OSM'ers in the UK, [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]]).<br />
* Similar to this, measure for fence panels and drop stillage appropriately, to avoid the need to carry loads of them right up the camping field by hand<br />
* Make it longer! There was loads of cool stuff I didn't have change to check out :( After all that work everyone does, it was a shame I couldn't experience it all! ([[User:Chewie|Chewie]])<br />
* Visibility of presentations in tents (brighter projectors/darker tents??) ([[User:StuartL]]) [+2]<br />
* washing points over drains/soakaway so the ground doesn't get muddy ([[User:Chewie|Chewie]]) [+3]<br />
* Mark out/allocate spaces for villages who had pinpointed locations on maps ([[User:Markp]]) [+1]<br />
* Use more plasma screens in stages instead of projectors ([[User:Markp]]). Or (better, as then the speaker can point to things) black fabric shades for the screen or marquee roof<br />
* Improved arrangements for washing and washing up (and handling the waste water from that) [+1]<br />
* Provide sanitizer gel dispensers at water points and near loos [+1]<br />
* Have the schedule linked off the EMF main page<br />
* Distribute and display paper schedules (even if their might be some last-minute changes) [+2]<br />
** Or have small screens at the entrances to tents showing what's currently on & what's next.<br />
* Much more workshop activity (more hands-on electronics and physical making) [+5]<br />
* Do have component vendors (maybe at their cost for marquee/power/space)<br />
** This is very difficult without a clear list of what will sell, as CPC was arranged to appear but wanted advisement ([[User:Stanto]])<br />
* Pick a flatter site (for ease of disabled access)<br />
* Ask speakers for bio's to include with their abstracts. Given them an abstract length up-front instead of editing it in an ad hoc way. Confirm acceptance to speakers and workshop organisers earlier.<br />
** Do this after talks have been accepted. I didn't write my talk so didn't know details until I got the OK.<br />
* Make and enforce a clear music curfew (say from midnight or 1am or 2am to 8 or 9am or 10am), to defend those sleeping from (eg) the technoevangelists and the drunk [+4]<br />
** Perhaps try to select a site next time where we can make part of the site to be a quiet area, eg a part surrounded by trees for natural sound insulation. Then enforce a noise curfew there. I'm not keen on the idea of having a noise curfew covering the entire camp though. [[User:Alecjw]] [+1]<br />
** Seconding enforced quiet/family camping area, but no overall noise curfew. It didn't take long to get away from the worst noise, and the end of the field by the kids' area was incredibly quiet (though strangely empty!!)<br />
* Loos not so near food vendors (pong + visible urinals offputting) [+5]<br />
* stronger enforcement/signage of quiet camping area [+4]<br />
* an explicit invitation (with clear instructions) to report Code of Conduct violations in open ceremony, brochure, Twitter, etc. We had no direct reports to Team Comfort, but several anecdotal tweets after the event -- when it's much too late. [[User:Martind|Martind]] ([[User talk:Martind|talk]]) 20:58, 1 September 2014 (UTC) [+1]<br />
* quieter, less-enclosed and more spacious bar (I suffer from social anxiety when I'm closed in with crowds, so I had a very sober emf!). [[User:Jane C|Jane C]]<br />
** perhaps an outdoor seating area if a larger marquee is too costly.<br />
* use our collective knowledge of technology to sort accessibility issues <br />
**ring-fence money for things like closed-loop in the stages early on. <br />
**ask people about their access requirements much earlier on - e.g. when they buy a ticket - so that there is more time to meet these requirements (or reach a workable compromise)<br />
**Build some kind of working system for preventing able-bodied people from using the disabled loos and showers (radar keys that only work when the loo is empty?) [[User:Jane C|Jane C]]<br />
* Info desk didn't seem to have the details wrt. volunteers, so when I volunteered I was sent out and found I wasn't needed. Suggest splitting the job - having a volunteer team leader (or several, in shifts) whose job it is to know who is where and also to make sure nobody gets stuck on a gate for 12 hours (eg. rotating people to more interesting places every couple of hours). ([[User:TonyHoyle|TonyHoyle]])<br />
* Also similar to this, a register of 'on call' people - excess volunteers who can deal with sudden demands for people (esp. in the case of fire I can imagine this would be extremely useful - you'd potentially need to cordon off a largish area very quickly, and that takes people. More mundane reasons would be a talk/workshop accumulating a large queue that needs managing). ([[User:TonyHoyle|TonyHoyle]])<br />
* add GPS or other location aware technology like BTLE/iBeacon to the badges for automatic now/next notifications [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]]).<br />
<br />
==Suggestions==<br />
* Ask for an optional email address for each ticket to go on your announce only mailing list. Only the person that bought the tickets got your emails and they were slow to forward them on meaning most messages were received too late.<br />
* Ask for age of children when booking, to give better planning stats for workshops etc. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* A talk (a bit like lightning talks) where people are given 5-10 minutes to share what they did with the previous event's badge. (If someone sends me the competition winners/runners up, I'll co-ordinate it) [[User:MatS|MatS]] ([[User talk:MatS|talk]]) 07:54, 1 September 2014 (UTC)<br />
* Pre-paid accounts for spending money on food/beer/whatever to negate need for cash ([[User:Markp]])<br />
* Have a fleet of communal wheel-barrows to help people transport their stuff from car to campsite [+1]<br />
** Stepney City Farm have a fleet of broken wheelbarrows – fix ’em, use ’em, everybody wins! ([[User:Andylolz]])<br />
** Or purchase some sack trolleys<br />
* contactless payment gear for food, beer, workshops<br />
** We had contactless payment for beer! (And we also offered cashback.) We should have messaged that better. Contactless payment for other things is complex, as we don't really control them. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
* forewarn food vendors to expect all-day demand, not just mealtimes, so they can stock and staff appropriately [+1]<br />
** food vendors were pretty much *events* caterers, used to feeding people snacks/lunch, we need *festival* caterers who are used to feeding people who are staying for a number of days. thethalicafe.co.uk? bedouin tent (shambala)? +late night options [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
*** It's really difficult to get caterers. Now we're a bit better known it's getting easier. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
* pinboard (offline) notice board everyone can contribute to (lost property, mini event notices eg rocket launches, would like to meet.., etc) [+1]<br />
* Ask people who want to give workshops if they'd be happy to give more than one session - the blacksmiths' output was extreme, but even giving two or three sessions would greatly increase the % of attendees who could sign up.<br />
* Sign-ups some kind of "express preference" systems, so most people (including those who don't check email regularly) can get at least one of their top choices, rather than first-come-first-served.<br />
* Board games tent in the evenings [+4]<br />
* Poker tent<br />
* Be less ambitious with badge functionality [+3]<br />
** And provide full documentation of features/functionality [+1]<br />
** And sample code for each function<br />
** Perhaps a back-to-basics through-hole design that comes with soldering iron, solder and instructions?<br />
** I think we might build on this design for the next event. [[User:Russ|Russ]] ([[User talk:Russ|talk]])<br />
** Software that doesn't involve an OS (but rather more conventional Arduinoery) might be more easily hackable by others during/after the event? Especially given libraries for people to do amusing things with the peer-to-peer radio...<br />
* EMF is unlike other festivals - for a large number of people, carrying kit to/from car is impractical and security walking every car through site is time-consuming and volunteer-intensive (not to mention the fact that cars driving off site weren't walked off). Suggest that the parking area is directly next to and easily accessible from the camping area (e.g. just separated by hay bales to stop cars driving on to the camping area).<br />
** As a village/car user you could generally provide your own security person walking in front of the car. This works 2 fold: 1) security doesn't need to walk for you 2) less waiting time for you since you already provide someone to walk.<br />
** The plan for this was to allow people to drive onto site on the Thursday evening. It wasn't very well communicated and we had a *very* tight setup schedule so we needed to reduce this as much as possible. This is ultimately an issue with our setup schedule<br />
** It wouldn't work on this site, but for some locations it might be possible to have a drop-off point close to camping (with a limited number of cars at one time), better idea than having cars (ignition source) close to tents. Some people were taking the mickey on Monday morning, many people driving onto site that could have carried things instead tying up volunteer resources to escort them.<br />
* Provide job descriptions for traffic control, parking and entrance gatehouse. Instructions were handed from volunteer to volunteer by word of mouth and whilst common sense prevailed, it would have been useful to have instructions as to what to do under certain circumstances and a list of answers to FAQs, e.g.:<br />
** What if somebody didn't have a parking ticket and wanted to park?<br />
** What if somebody was just dropping off - where should they do this?<br />
** What times were shuttle buses running?<br />
** What times the gates were open/closed?<br />
** Have a priority queue for people with machine readable tickets (ie paper!)<br />
* Add suggested age ranges for all workshops, some of the "adult" workshops were also very suitable for children (e.g. electronic fashion, solar pv) or could have been run once in main workshop once in kid's area [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* Bolt the fence from the right side, I know we didn't even want it at all but local authorities can be fussy, I've been at a festival before who did the same and they made them fix it during the event.. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* Want the good coffee on Monday morning, especially for drivers :) Maybe in the car park to help persuade people off site. [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
* Would be good to have eggs, fresh milk, bacon at the shop (there was a comment like "we don't have eggs, they break too easily" - so charge extra to cover this, though it's probably not as bad as you think..) [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]])<br />
** Morrisons did a tent with Milk, Bread, Burgers, BBQs etc @ http://www.festivalofcycling.org/expo/name/morrisons/, might be worth asking them? [[User:Jburgess777|Jburgess777]] ([[User talk:Jburgess777|talk]])<br />
* Start ticket sales (a couple of months?) earlier, maybe with a slightly bigger difference between early ticket prices and full price to encourage attendees to get in early (which in turn would improve cashflow) [[User:Sthen|Sthen]] ([[User talk:Sthen|talk]]) [+1]<br />
* Start ticket sales *now* whilst you have all the publicity or at least have a page up where people can register to be emailed once the next event has tickets for sale. That way you get your current mailing list + everyone else who has only just learned about it as your audience. [[User:Alteralias|Alteralias]]<br />
* Cluster the talks into related-topic sessions<br />
* Volunteering stuff ([[User:HughePaul|HughePaul]])<br />
** Whiteboard in info tent for current issues / tasks, handover<br />
** Have info tent next to security tent so both can be available at the same time and all the time.<br />
*** The info tent and the gatehouse/security tent could be two sides of the same erection.<br />
** have predefined named people in shifts for head of / coordination of volunteering (could also double as an info/security tent staff)<br />
** maybe stream some talks in info tent so they don't feel like they are missing things<br />
** more formal defined (and communicated) lost-property form and procedure<br />
** define volunteer job roles to make handovers easier and so we know what we are meant to be doing<br />
* Have dedicated blog / tweet / website updating person/team<br />
* big screen with latest official event update tweets<br />
* info about getting DISconnected from DKs and leaving the site in vehicles</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Packing_List&diff=2869Packing List2014-08-24T11:46:38Z<p>Jonty: /* Optional */</p>
<hr />
<div>An example packing list and some optional things you might want to think about bringing:<br />
<br />
==Basics==<br />
<br />
Basic stuff you will almost certainly need:<br />
<br />
* Somewhere to sleep: tent (make sure you have all the bits), camper van, covered hammock etc<br />
* Sleeping bag / blanket and air mattress / camp bed if you don't want to sleep on hard ground<br />
* Enough (appropriate) clothing for the weekend including:<br />
* Sunglasses / hat / sunscreen if it looks to be remotely warm<br />
* Waterproof jacket / trousers / jumpers if it looks to be remotely cold <br />
* Torch, with enough batteries for the weekend (consider having torch with rechargeable battery)<br />
* Wash stuff: soap, flannel, toothbrush, toothpaste, shampoo<br />
* Towel<br />
* Toilet paper<br />
* First aid kit<br />
* Any medication you need<br />
* Insect repellent<br />
* Water bottle<br />
* Carrier bags for dirty or wet clothes<br />
* Chargers for anything battery powered you bring<br />
* Bin bags for your [[Team:Sanitation#Rubbish_.26_Recycling|Rubbish]]<br />
<br />
==Cooking==<br />
<br />
There will be multiple caterers on the site, so you won't have to cook if you don't want to, but if you plan on cooking things on site:<br />
<br />
* Something to cook on: gas / meths burner, BBQ, raised fire (See FAQ for rules re. fires, NB there will be communal BBQs available)<br />
* Fuel for above<br />
* Something to ignite above: matches, lighter etc.<br />
* Pots, pans, crockery and cutlery, cups etc.<br />
* Washing up liquid <br />
<br />
==Optional==<br />
<br />
Some optional stuff you might want to think about bringing:<br />
<br />
* A computer - some of the workshops require a laptop, and we have all kinds of things online<br />
* If you want power to your tent, 25m mains extension cable (with a UK 13A or 16A ceeform plug)<br />
* A chair, or something else to sit on<br />
* Something to carry/store water for cooking & drinking<br />
* Pocket knife<br />
* Spare socks (for sleeping in if it's cold)<br />
* Ear plugs<br />
* Rope<br />
* Duct tape<br />
* Long (30 - 40m) cat5 ethernet cable to connect your tent<br />
* Short (2 - 5m) cat5 ethernet cable to use when in venues<br />
* An old mobile phone if you wish to connect to our on-site phone network. Must take a standard SIM card.<br />
<br />
==What not to bring==<br />
<br />
* Try to avoid bringing glass. Glass is heavy, and broken glass is a pain to clean up in a field.<br />
* Wireless access points. We'll have good WiFi; any other access points will just interfere.<br />
* Beer or wine: we will have plenty and we'll be selling it at better-than-pub prices, with all the profits going towards the next camp. (We won't be selling spirits, so feel free to bring those.)<br />
* Animals (except registered guide dogs).</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Packing_List&diff=2868Packing List2014-08-24T11:46:14Z<p>Jonty: /* Optional */</p>
<hr />
<div>An example packing list and some optional things you might want to think about bringing:<br />
<br />
==Basics==<br />
<br />
Basic stuff you will almost certainly need:<br />
<br />
* Somewhere to sleep: tent (make sure you have all the bits), camper van, covered hammock etc<br />
* Sleeping bag / blanket and air mattress / camp bed if you don't want to sleep on hard ground<br />
* Enough (appropriate) clothing for the weekend including:<br />
* Sunglasses / hat / sunscreen if it looks to be remotely warm<br />
* Waterproof jacket / trousers / jumpers if it looks to be remotely cold <br />
* Torch, with enough batteries for the weekend (consider having torch with rechargeable battery)<br />
* Wash stuff: soap, flannel, toothbrush, toothpaste, shampoo<br />
* Towel<br />
* Toilet paper<br />
* First aid kit<br />
* Any medication you need<br />
* Insect repellent<br />
* Water bottle<br />
* Carrier bags for dirty or wet clothes<br />
* Chargers for anything battery powered you bring<br />
* Bin bags for your [[Team:Sanitation#Rubbish_.26_Recycling|Rubbish]]<br />
<br />
==Cooking==<br />
<br />
There will be multiple caterers on the site, so you won't have to cook if you don't want to, but if you plan on cooking things on site:<br />
<br />
* Something to cook on: gas / meths burner, BBQ, raised fire (See FAQ for rules re. fires, NB there will be communal BBQs available)<br />
* Fuel for above<br />
* Something to ignite above: matches, lighter etc.<br />
* Pots, pans, crockery and cutlery, cups etc.<br />
* Washing up liquid <br />
<br />
==Optional==<br />
<br />
Some optional stuff you might want to think about bringing:<br />
<br />
* A computer - some of the workshops require a laptop, and we have all kinds of things online<br />
* A chair, or something else to sit on<br />
* Something to carry/store water for cooking & drinking<br />
* Pocket knife<br />
* Spare socks (for sleeping in if it's cold)<br />
* Ear plugs<br />
* Rope<br />
* Duct tape<br />
* Long (30 - 40m) cat5 ethernet cable to connect your tent<br />
* Short (2 - 5m) cat5 ethernet cable to use when in venues<br />
* If you want power to your tent, 25m mains extension cable (with a UK 13A or 16A ceeform plug)<br />
* An old mobile phone if you wish to connect to our on-site phone network. Must take a standard SIM card.<br />
<br />
==What not to bring==<br />
<br />
* Try to avoid bringing glass. Glass is heavy, and broken glass is a pain to clean up in a field.<br />
* Wireless access points. We'll have good WiFi; any other access points will just interfere.<br />
* Beer or wine: we will have plenty and we'll be selling it at better-than-pub prices, with all the profits going towards the next camp. (We won't be selling spirits, so feel free to bring those.)<br />
* Animals (except registered guide dogs).</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=EMF_Milliways_Dome_Pledge&diff=2771EMF Milliways Dome Pledge2014-08-22T15:07:29Z<p>Jonty: </p>
<hr />
<div>At every hacker/maker camp in europe you'll find Milliways, the restaurant at the end of the universe. Or in our case the end of the field.<br />
<br />
Milliways are a volunteer run kitchen who tour around the camps cooking for anybody who wants food in return for donations. They have a full kitchen and even bake bread in the middle of the camp! This year Milliways are helping EMF by providing food and cooking equipment to all our set-up and tear-down volunteers, as well as reprising their usual role as a fun place to hang out and get fed. In return, EMF is providing a large marquee for them.<br />
<br />
Milliways have an AWESOME giant geodesic dome they bring to the camps to use as shelter - both for people eating, and for people to relax under in the evening. They're bringing it over from Germany but it costs a lot of money to do so. We'd really like to help them out but the EMF budget is totally exhausted, so we're having a whip-round to try and raise a bit more money.<br />
<br />
If you'd like to sit under a massive geodesic dome and drink beer next weekend, please donate a little money to the cause.<br />
<br />
<br />
'''Plan:''' Try and raise some money to help cover Milliways costs bringing over a huge geodesic dome<br />
<br />
'''Costings:''' They're already paying for it, but we'd like to raise £500 to help them out<br />
<br />
'''Pledges''' (please edit to add your support)<br />
* £25 - Jontyw<br />
* £20 - Jane C<br />
* £5 - --[[User:Msemtd|Msemtd]] ([[User talk:Msemtd|talk]]) 14:53, 22 August 2014 (UTC)<br />
* £50 - [[User:Ms7821|Mark]]<br />
* £20 - [[User:ens|ens]]<br />
* £30 - Crypt<br />
<br />
'''Total: £150'''</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=EMF_Milliways_Dome_Pledge&diff=2768EMF Milliways Dome Pledge2014-08-22T14:59:45Z<p>Jonty: </p>
<hr />
<div>At every hacker/maker camp in europe you'll find Milliways, the restaurant at the end of the universe. Or in our case the end of the field.<br />
<br />
Milliways are a volunteer run kitchen who tour around the camps cooking for anybody who wants food in return for donations. They have a full kitchen and even bake bread in the middle of the camp! This year Milliways are helping EMF by providing food and cooking equipment to all our set-up and tear-down volunteers, as well as reprising their usual role as a fun place to hang out and get fed. In return, EMF is providing a large marquee for them.<br />
<br />
Milliways have an AWESOME giant geodesic dome they bring to the camps to use as shelter - both for people eating, and for people to relax under in the evening. They're bringing it over from Germany but it costs a lot of money to do so. We'd really like to help them out but the EMF budget is totally exhausted, so we're having a whip-round to try and raise a bit more money.<br />
<br />
If you'd like to sit under a massive geodesic dome and drink beer next weekend, please donate a little money to the cause.<br />
<br />
<br />
'''Plan:''' Try and raise some money to help cover Milliways costs bringing over a huge geodesic dome<br />
<br />
'''Costings:''' They're already paying for it, but we'd like to raise £500 to help them out<br />
<br />
'''Pledges''' (please edit to add your support)<br />
* £25 - Jontyw<br />
* £20 - Jane C<br />
* £5 - --[[User:Msemtd|Msemtd]] ([[User talk:Msemtd|talk]]) 14:53, 22 August 2014 (UTC)<br />
* £50 - [[User:Ms7821|Mark]]<br />
<br />
'''Total: £100'''</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=EMF_Milliways_Dome_Pledge&diff=2767EMF Milliways Dome Pledge2014-08-22T14:59:34Z<p>Jonty: </p>
<hr />
<div>At every hacker/maker camp in europe you'll find Milliways, the restaurant at the end of the universe. Or in our case the end of the field.<br />
<br />
Milliways are a volunteer run kitchen who tour around the camps cooking for anybody who wants food in return for donations. They have a full kitchen and even bake bread in the middle of the camp! This year Milliways are helping EMF by providing food and cooking equipment to all our set-up and tear-down volunteers, as well as reprising their usual role as a fun place to hang out and get fed. In return, EMF is providing a large marquee for them.<br />
<br />
Milliways have an AWESOME giant geodesic dome they bring to the camps to use as shelter - both for people eating, and for people to relax under in the evening. They're bringing it over from Germany but it costs a lot of money to do so. We'd really like to help them out but the EMF budget is totally exhausted, so we're having a whip-round to try and raise a bit more money.<br />
<br />
If you'd like to sit under a massive geodesic dome and drink beer next weekend, please donate a little money to the cause.<br />
<br />
<br />
'''Plan:''' Try and raise some money to help cover Milliways costs bringing over a huge geodesic dome<br />
<br />
'''Costings:''' They're already paying for it, but we'd like to raise £500 to help them out<br />
<br />
'''Pledges''' (please edit to add your support)<br />
* £25 - Jontyw<br />
* £20 - Jane C<br />
* £5 - --[[User:Msemtd|Msemtd]] ([[User talk:Msemtd|talk]]) 14:53, 22 August 2014 (UTC)<br />
* £50 - [[User:Ms7821|Mark]]<br />
<br />
'''Total: £50'''</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=EMF_Milliways_Dome_Pledge&diff=2761EMF Milliways Dome Pledge2014-08-22T14:48:59Z<p>Jonty: Created page with "At every hacker/maker camp in europe you'll find Milliways, the restaurant at the end of the universe. Or in our case the end of the field. Milliways are a volunteer run kitc..."</p>
<hr />
<div>At every hacker/maker camp in europe you'll find Milliways, the restaurant at the end of the universe. Or in our case the end of the field.<br />
<br />
Milliways are a volunteer run kitchen who tour around the camps cooking for anybody who wants food in return for donations. They have a full kitchen and even bake bread in the middle of the camp! This year Milliways are helping EMF by providing food and cooking equipment to all our set-up and tear-down volunteers, as well as reprising their usual role as a fun place to hang out and get fed. In return, EMF is providing a large marquee for them.<br />
<br />
Milliways have an AWESOME giant geodesic dome they bring to the camps to use as shelter - both for people eating, and for people to relax under in the evening. They're bringing it over from Germany but it costs a lot of money to do so. We'd really like to help them out but the EMF budget is totally exhausted, so we're having a whip-round to try and raise a bit more money.<br />
<br />
If you'd like to sit under a massive geodesic dome and drink beer next weekend, please donate a little money to the cause.<br />
<br />
<br />
'''Plan:''' Try and raise some money to help cover Milliways costs bringing over a huge geodesic dome<br />
<br />
'''Costings:''' They're already paying for it, but we'd like to raise £500 to help them out<br />
<br />
'''Pledges''' (please edit to add your support)<br />
* £25 - Jontyw<br />
<br />
'''Total: £25'''</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Whiskyleaks&diff=2645Whiskyleaks2014-08-21T21:39:59Z<p>Jonty: </p>
<hr />
<div>Carrying on [https://ohm2013.org/wiki/Whiskyleaks the tradition]. Bring a bottle (or more) of nice whisky. You might just be able to get away with whiskey.<br />
<br />
When: Saturday August 30th at 21:30<br><br />
Where: TBC (probably [[Villages:London Hackspace]] or Milliways)<br />
<br />
If you're coming, add your name and what you're bringing:<br />
<br />
* [[User:Russ|Russ]] (something from SMWS)<br />
* [[User:Jonty|Jonty]] (something from SMWS)</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=FAQ&diff=2059FAQ2014-08-18T15:27:27Z<p>Jonty: /* Can I make a fire, or bring my own BBQ? */</p>
<hr />
<div>{{link-banner}}<br />
This is a work in progress. Keep checking for updates.<br />
<br />
==General==<br />
===Who are you?===<br />
Electromagnetic Field is run by a non-profit organisation and produced entirely by volunteers. We are members of well-known hackerspaces and other organisations. Get in touch if you want to join us in making this happen.<br />
<br />
===Why are you doing this?===<br />
There now are dozens of hackerspaces and makerspaces in the UK and across Europe, and countless other communities of craftsmen, artists, designers, engineers who are interested in the same DIY ethic; but they have few opportunities to all meet up. Most events catering to these communities are small regional conferences and often focused on very specific themes.<br />
<br />
We want to change that :)<br />
<br />
===Why Milton Keynes?===<br />
We looked at a fair number of candidate sites. The site we ended up with was the best candidate for a number of reasons:<br />
* It comes at a comparably low price (some of the candidate sites we looked at asked for tens of thousands of £££.)<br />
* It has great transport links to much of the UK (both roads and trains.)<br />
* It is close(ish) to a few data centres and high speed Internet uplinks.<br />
* We were there last time and it seemed to work well<br />
Bonus: it is very close to Bletchley Park :)<br />
<br />
===How big is it?===<br />
<br />
In 2012, we had an attendance limit of 500 and fully sold out. This year we are expecting around 1,200 people. Buy your ticket early to avoid disappointment.<br />
<br />
==Ticket Sales==<br />
===How can I get a ticket?===<br />
Tickets are on sale from our web site here:<br />
<br />
'''https://www.emfcamp.org/tickets/choose'''<br />
<br />
This time there will be no day tickets and camp tickets are likely to sell out in advance.<br />
<br />
===How much does it cost?===<br />
Adult tickets are currently £105. There are tickets available for under-16s at a lower price (accompanied by an adult). Children under 5 can attend for free.<br />
<br />
If you have a Camper van you will need a Camper van ticket. <br />
<br />
If you want to bring a car you'll also need a car parking ticket.<br />
<br />
You can pay by bank transfer (in pounds sterling or Euros), a one-time direct debit (in pounds sterling or Euros), or by credit or debit card via Stripe (which charges a small fee).<br />
<br />
===What's the accessibility situation like?===<br />
The site will be well lit during the event, and we will aim to cover access to the stages with trackway. Travelling between stages may take some time, though.<br />
<br />
There will be three accessible toilets and the current plan includes an accessible shower with a wheelchair ramp.<br />
<br />
We cannot guarantee 24/7 power for continuous positive airway pressure (CPAP) devices, but the power infrastructure team will be on call through the night.<br />
<br />
If you will be attending with a carer, they are entitled to a free ticket. Please [mailto:tickets@emfcamp.org email us] in advance so we can allocate the ticket.<br />
<br />
Registered assistance dogs will be allowed.<br />
<br />
If you have any other requirements, please tick the "I have accessibility requirements" checkbox when buying your ticket, and we'll be in touch for details. If you'd like to confirm anything before buying your ticket, please [mailto:tickets@emfcamp.org drop us an email].<br />
<br />
===Can I get a day ticket?===<br />
Sorry, EMF 2012 was sold to capacity and we found that the day tickets prevented people from attending the whole event. For this reason, we can only offer tickets for the whole event. You are welcome to only come to one day, or to stay off-site and attend only during the days, but you will need a weekend ticket.<br />
<br />
===Can I get a family ticket?===<br />
Unfortunately, as every attendee including children counts towards our capacity limit, we are unable to offer family or group tickets. We have however already discounted the child ticket prices by 60% which is as far as the budget allows.<br />
<br />
===Will I be able to turn up and buy a ticket?===<br />
It is unlikely that any tickets will remain by the time of the event. Watch this space.<br />
<br />
===Do volunteers pay for their ticket?===<br />
Everyone who attends is expected to buy a ticket, including people in the organising team and all volunteers. So many people contribute to running EMF that it would financially impossible to give everyone who helps out a free ticket, and unfair to draw a line past which volunteers receive free tickets.<br />
<br />
The only exception to this rule are first aiders, who are expected to carry out three 8-hour shifts in return for a free ticket.<br />
<br />
===Is there an age limit?===<br />
We encourage children and young people to attend. We are planning specific activities for children as well as daycare facilities, and will confirm more details nearer to the time.<br />
<br />
However there are a number of things to bear in mind:<br />
* Children under the age of 14 must be accompanied by an adult at all times.<br />
* There will be dangerous things on site, but they will be clearly marked.<br />
* Licensed alcohol sales are only for people of age 18 and over. Bar staff will ask for ID.<br />
<br />
===Can't enter the transaction reference?===<br />
If you are having trouble entering the transaction reference into your online banking, just remove the hyphen. Some banks don't like it and don't tell you.<br />
<br />
===What's your IBAN/BIC details?===<br />
Select a ticket valued in EUR on the front page. You will be presented with the necessary IBAN/BIC transfer details. Foreign transactions are not supported for GBP tickets.<br />
<br />
===Do you have a Code of Conduct?===<br />
Yes, please see [https://www.emfcamp.org/code-of-conduct Code of conduct]. If you buy a ticket you are agreeing to abide by this.<br />
<br />
===What terms and conditions apply to ticket sales and attendance?===<br />
Please see our [https://www.emfcamp.org/pay/terms terms] page.<br />
<br />
===Can I pay more? TAKE MY MONEY!===<br />
<br />
If you can afford it and wish to help support the event financially by paying a bit more for your ticket, you can buy a Supporter ticket. We're a non-profit event and so the money will go towards making the event even more awesome.<br />
<br />
==Planning your Attendance==<br />
===Where is it? How can I get there?===<br />
Refer to [[Location]]. '''NOTE: We have moved!''' It's only a few miles down the road, but please don't go to the old site!<br />
<br />
===When can I arrive? When do I have to leave by?===<br />
The site will open to ticket holders at 10:00 Friday morning.<br />
<br />
All ticket holders must leave the site by 12:00 Monday.<br />
<br />
We will be there before and afterwards setting up and packing up, if you want to help with this please let us know and we can make arrangements. It's worth noting outside these times we can't guarantee availability of toilets/water/electricity/internet etc.<br />
<br />
Have a look at our Timeline for an updated summary.<br />
<br />
===When do things kick off?===<br />
The talks and workshops will begin after lunch on Friday, although people will be setting up earlier in the day. You can arrive from 10am.<br />
<br />
Talks and workshops run daily through to the evening, although we expect villages will be doing things late into the night!<br />
<br />
===What should I bring?===<br />
Please take a look at our [[Packing List]] for information on what you should and shouldn't bring.<br />
<br />
===Will there be food?===<br />
We appreciate we didn't do well at this last time. This year we have lined up multiple food stalls, hopefully catering to all your needs. Initial details are at [[Food]]<br />
<br />
===Will there be a bar?===<br />
Yes, we'll be running a volunteer-staffed licensed bar selling beer and wine, as well as soft drinks and the hacker energy drink Club Mate. Far from the usual crap festival beer, we will be serving real ale from local breweries with all profits going towards making the next iteration of Electromagnetic Field more awesome.<br />
<br />
The bar on site opening hours are subject to licensing which will be finalised soon.<br />
<br />
By the camping areas there will also be push taps of drinking water available for free.<br />
<br />
===Can I bring pets?===<br />
Sorry, animals (except registered assistance dogs) are not allowed.<br />
<br />
===Can I smoke?===<br />
Smoking is not allowed in any of the event tents or in the food/bar area. Elsewhere, please be considerate and very careful to extinguish your cigarettes to avoid setting the dry grass on fire. Please make sure cigarette butts are disposed of in rubbish bins rather than just thrown on the ground as the site is used by livestock at other times of the year, and it's a pain for the clean up crew to pick them up after the camp is over!<br />
<br />
===Can I bring X/Y/Z?===<br />
tl;dr Probably<br />
<br />
Please let us know if it's going to be large/use a lot of power/be noisy or anything else you think we should know. We don't plan on stopping people bringing the latest cool laser helmet for shark 3d printer arduino powered UAV thing, but we need to plan for it. Note that access to the site is several hundred metres from the carpark and you will not be able to drive up to the site.<br />
<br />
Things prohibited by our contract: balloons, sky lanterns and the like.<br />
<br />
===Can I leave and re-enter?===<br />
Your wristband will allow re-admittance, but the site is gated and we will be trying to restrict movements to daylight hours. In reality this is unlikely to be a problem, but please speak to us if you have any special requirements. The farm gate is locked overnight and would require a volunteer to come up to let you out.<br />
<br />
Please note that it is a condition of our contract that we don't allow you to roam the farm. Apart from anything else, there is likely to be heavy farm machinery in operation. For this reason, the entire event area is fenced off. We can shuttle you to the parking area, from where you may drive off the site or be collected.<br />
<br />
==Camp Infrastructure==<br />
===Can I see the camp layout?===<br />
We're working on this at the moment. Some initial information can be found at: [[Location]].<br />
<br />
You can see the site map at [http://map.emfcamp.org/ map.emfcamp.org]. Please note that this is still in early stages of development; we know it is slow and has bugs, don't worry about reporting them. All layout is still subject to change.<br />
<br />
===Is there parking available?===<br />
Yes. Parking tickets are on sale with tickets. Please note the car park is not adjacent to the site, but there will be a shuttle. You will not be able to drive up to or onto the site to drop anything off.<br />
<br />
If you don't yet know whether you will be bringing a car, you can buy your event ticket now and buy a parking ticket at a later date (deadline to be announced, probably early August).<br />
<br />
Parking tickets are not required for motorcycles.<br />
<br />
===Can I bring my camper van?===<br />
We have limited parking for camper vans - you can buy a ticket for £30 through our tickets site. These tickets include a parking ticket for the towing car in the car park.<br />
<br />
===Will there be Internet access?===<br />
Yes, we are provisioning onsite high speed wifi and wired access (direct to your tent!), see [[Network]].<br />
<br />
===Can I make a fire, or bring my own BBQ?===<br />
<br />
Fires on the ground are strictly prohibited. Please adhere to this requirement of both the landowner and health and safety.<br />
<br />
Barbecues must be used off the ground. If you have a raised fire pit this is also acceptable.<br />
<br />
Foraging for wood on the site is not permitted according to the terms of our contract with the landowners. Please bring your own fuel to site.<br />
<br />
===I see a lake on the satellite image. Can I do X in it?===<br />
<br />
The lake and brook are out of bounds by order of the site owner!<br />
<br />
===What about medical cover?===<br />
<br />
We will have our our own lovely volunteer first aiders + SJA coverage.<br />
<br />
==Getting Involved==<br />
===What will I be able to do?===<br />
We're planning a full line up of speakers and workshops as well as awesome things around the site. We will also be supporting community organised 'villages' and looking for volunteers to help run the event.<br />
<br />
===What is a 'Village'?===<br />
Villages are camps organised around a theme, it could be anything, but is often a location or a topic (e.g. lock-picking). By organising villages ahead of time we can help provide better equipment (e.g. large tents to use) as well as making sure that they have an area ahead of time. If you want to find out more about villages, join one or see what villages have already been organised check the [[Villages]] page.<br />
<br />
===How do I give a talk/run a workshop?===<br />
<br />
The [https://www.emfcamp.org/cfp Call for Participation] is now open, so if you want to give a talk or run a workshop, please fill in the form soon. We really want a wide variety of topics from as diverse a group of people as we can, so don't be shy! If you've missed the CfP then don't worry, there will be [http://en.wikipedia.org/wiki/Lightning_talk lightning talk] sessions and villages are welcome to run their own talks and workshops.<br />
<br />
===Would people be interested in a talk on X?===<br />
Yes. There are obviously a few caveats on that but they're covered in the [https://www.emfcamp.org/cfp Call for Participation]<br />
<br />
===I want to bring/make something awesome, can you help?===<br />
Hopefully. We have a limited budget to put towards making the camp amazing and we want to share it with those of you who will bring awesome things. At EMF2012 we had a giant hammock, floating LEDs, a wooden dinosaur and 'EMF' written in 5m tall steel letters. If there's something amazing that you'd like to make and bring along but need some help buying materials we'll be opening our submissions process soon.<br />
<br />
===How do I volunteer?===<br />
The easiest way is to tick the 'interested in volunteering' box when you buy your ticket (sorry volunteers still need a ticket). If you missed it don't worry you can volunteer at any time by signing in and ticking the box. Once you've signed up to volunteer we'll get in contact with you closer to the time to organise shifts.<br />
<br />
==Villages==<br />
=== Can we reserve a location for our village? ===<br />
No, not really. What is possible is to obtain an advisory lock on a certain general area, but there will be no reservation system in place and if your village shows up late the spot may be taken.<br />
<br />
=== When can I build my village? ===<br />
we are working on answering that question very soon. This mainly relies on toilets, water and power being availible. We will post some information later on the [[Villages|village page]] in the wiki.<br />
<br />
=== Our village wants to rent a tent, is that possible? ===<br />
We are working on that, information about that will be added to [[Villages|the wiki]] when availible. <br />
<br />
=== Our village is planning a cool workshop / performance / ..., can the program mention it? ===<br />
We'd really like to do that! Please [mailto:contact@emfcamp.org get in touch].<br />
<br />
=== Our village is really big, does that need special planning? ===<br />
Probably: yes. Please contact general@lists.emfcamp.org, the single point of contact for all things villages concern so far.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=FAQ&diff=2058FAQ2014-08-18T15:26:47Z<p>Jonty: </p>
<hr />
<div>{{link-banner}}<br />
This is a work in progress. Keep checking for updates.<br />
<br />
==General==<br />
===Who are you?===<br />
Electromagnetic Field is run by a non-profit organisation and produced entirely by volunteers. We are members of well-known hackerspaces and other organisations. Get in touch if you want to join us in making this happen.<br />
<br />
===Why are you doing this?===<br />
There now are dozens of hackerspaces and makerspaces in the UK and across Europe, and countless other communities of craftsmen, artists, designers, engineers who are interested in the same DIY ethic; but they have few opportunities to all meet up. Most events catering to these communities are small regional conferences and often focused on very specific themes.<br />
<br />
We want to change that :)<br />
<br />
===Why Milton Keynes?===<br />
We looked at a fair number of candidate sites. The site we ended up with was the best candidate for a number of reasons:<br />
* It comes at a comparably low price (some of the candidate sites we looked at asked for tens of thousands of £££.)<br />
* It has great transport links to much of the UK (both roads and trains.)<br />
* It is close(ish) to a few data centres and high speed Internet uplinks.<br />
* We were there last time and it seemed to work well<br />
Bonus: it is very close to Bletchley Park :)<br />
<br />
===How big is it?===<br />
<br />
In 2012, we had an attendance limit of 500 and fully sold out. This year we are expecting around 1,200 people. Buy your ticket early to avoid disappointment.<br />
<br />
==Ticket Sales==<br />
===How can I get a ticket?===<br />
Tickets are on sale from our web site here:<br />
<br />
'''https://www.emfcamp.org/tickets/choose'''<br />
<br />
This time there will be no day tickets and camp tickets are likely to sell out in advance.<br />
<br />
===How much does it cost?===<br />
Adult tickets are currently £105. There are tickets available for under-16s at a lower price (accompanied by an adult). Children under 5 can attend for free.<br />
<br />
If you have a Camper van you will need a Camper van ticket. <br />
<br />
If you want to bring a car you'll also need a car parking ticket.<br />
<br />
You can pay by bank transfer (in pounds sterling or Euros), a one-time direct debit (in pounds sterling or Euros), or by credit or debit card via Stripe (which charges a small fee).<br />
<br />
===What's the accessibility situation like?===<br />
The site will be well lit during the event, and we will aim to cover access to the stages with trackway. Travelling between stages may take some time, though.<br />
<br />
There will be three accessible toilets and the current plan includes an accessible shower with a wheelchair ramp.<br />
<br />
We cannot guarantee 24/7 power for continuous positive airway pressure (CPAP) devices, but the power infrastructure team will be on call through the night.<br />
<br />
If you will be attending with a carer, they are entitled to a free ticket. Please [mailto:tickets@emfcamp.org email us] in advance so we can allocate the ticket.<br />
<br />
Registered assistance dogs will be allowed.<br />
<br />
If you have any other requirements, please tick the "I have accessibility requirements" checkbox when buying your ticket, and we'll be in touch for details. If you'd like to confirm anything before buying your ticket, please [mailto:tickets@emfcamp.org drop us an email].<br />
<br />
===Can I get a day ticket?===<br />
Sorry, EMF 2012 was sold to capacity and we found that the day tickets prevented people from attending the whole event. For this reason, we can only offer tickets for the whole event. You are welcome to only come to one day, or to stay off-site and attend only during the days, but you will need a weekend ticket.<br />
<br />
===Can I get a family ticket?===<br />
Unfortunately, as every attendee including children counts towards our capacity limit, we are unable to offer family or group tickets. We have however already discounted the child ticket prices by 60% which is as far as the budget allows.<br />
<br />
===Will I be able to turn up and buy a ticket?===<br />
It is unlikely that any tickets will remain by the time of the event. Watch this space.<br />
<br />
===Do volunteers pay for their ticket?===<br />
Everyone who attends is expected to buy a ticket, including people in the organising team and all volunteers. So many people contribute to running EMF that it would financially impossible to give everyone who helps out a free ticket, and unfair to draw a line past which volunteers receive free tickets.<br />
<br />
The only exception to this rule are first aiders, who are expected to carry out three 8-hour shifts in return for a free ticket.<br />
<br />
===Is there an age limit?===<br />
We encourage children and young people to attend. We are planning specific activities for children as well as daycare facilities, and will confirm more details nearer to the time.<br />
<br />
However there are a number of things to bear in mind:<br />
* Children under the age of 14 must be accompanied by an adult at all times.<br />
* There will be dangerous things on site, but they will be clearly marked.<br />
* Licensed alcohol sales are only for people of age 18 and over. Bar staff will ask for ID.<br />
<br />
===Can't enter the transaction reference?===<br />
If you are having trouble entering the transaction reference into your online banking, just remove the hyphen. Some banks don't like it and don't tell you.<br />
<br />
===What's your IBAN/BIC details?===<br />
Select a ticket valued in EUR on the front page. You will be presented with the necessary IBAN/BIC transfer details. Foreign transactions are not supported for GBP tickets.<br />
<br />
===Do you have a Code of Conduct?===<br />
Yes, please see [https://www.emfcamp.org/code-of-conduct Code of conduct]. If you buy a ticket you are agreeing to abide by this.<br />
<br />
===What terms and conditions apply to ticket sales and attendance?===<br />
Please see our [https://www.emfcamp.org/pay/terms terms] page.<br />
<br />
===Can I pay more? TAKE MY MONEY!===<br />
<br />
If you can afford it and wish to help support the event financially by paying a bit more for your ticket, you can buy a Supporter ticket. We're a non-profit event and so the money will go towards making the event even more awesome.<br />
<br />
==Planning your Attendance==<br />
===Where is it? How can I get there?===<br />
Refer to [[Location]]. '''NOTE: We have moved!''' It's only a few miles down the road, but please don't go to the old site!<br />
<br />
===When can I arrive? When do I have to leave by?===<br />
The site will open to ticket holders at 10:00 Friday morning.<br />
<br />
All ticket holders must leave the site by 12:00 Monday.<br />
<br />
We will be there before and afterwards setting up and packing up, if you want to help with this please let us know and we can make arrangements. It's worth noting outside these times we can't guarantee availability of toilets/water/electricity/internet etc.<br />
<br />
Have a look at our Timeline for an updated summary.<br />
<br />
===When do things kick off?===<br />
The talks and workshops will begin after lunch on Friday, although people will be setting up earlier in the day. You can arrive from 10am.<br />
<br />
Talks and workshops run daily through to the evening, although we expect villages will be doing things late into the night!<br />
<br />
===What should I bring?===<br />
Please take a look at our [[Packing List]] for information on what you should and shouldn't bring.<br />
<br />
===Will there be food?===<br />
We appreciate we didn't do well at this last time. This year we have lined up multiple food stalls, hopefully catering to all your needs. Initial details are at [[Food]]<br />
<br />
===Will there be a bar?===<br />
Yes, we'll be running a volunteer-staffed licensed bar selling beer and wine, as well as soft drinks and the hacker energy drink Club Mate. Far from the usual crap festival beer, we will be serving real ale from local breweries with all profits going towards making the next iteration of Electromagnetic Field more awesome.<br />
<br />
The bar on site opening hours are subject to licensing which will be finalised soon.<br />
<br />
By the camping areas there will also be push taps of drinking water available for free.<br />
<br />
===Can I bring pets?===<br />
Sorry, animals (except registered assistance dogs) are not allowed.<br />
<br />
===Can I smoke?===<br />
Smoking is not allowed in any of the event tents or in the food/bar area. Elsewhere, please be considerate and very careful to extinguish your cigarettes to avoid setting the dry grass on fire. Please make sure cigarette butts are disposed of in rubbish bins rather than just thrown on the ground as the site is used by livestock at other times of the year, and it's a pain for the clean up crew to pick them up after the camp is over!<br />
<br />
===Can I bring X/Y/Z?===<br />
tl;dr Probably<br />
<br />
Please let us know if it's going to be large/use a lot of power/be noisy or anything else you think we should know. We don't plan on stopping people bringing the latest cool laser helmet for shark 3d printer arduino powered UAV thing, but we need to plan for it. Note that access to the site is several hundred metres from the carpark and you will not be able to drive up to the site.<br />
<br />
Things prohibited by our contract: balloons, sky lanterns and the like.<br />
<br />
===Can I leave and re-enter?===<br />
Your wristband will allow re-admittance, but the site is gated and we will be trying to restrict movements to daylight hours. In reality this is unlikely to be a problem, but please speak to us if you have any special requirements. The farm gate is locked overnight and would require a volunteer to come up to let you out.<br />
<br />
Please note that it is a condition of our contract that we don't allow you to roam the farm. Apart from anything else, there is likely to be heavy farm machinery in operation. For this reason, the entire event area is fenced off. We can shuttle you to the parking area, from where you may drive off the site or be collected.<br />
<br />
==Camp Infrastructure==<br />
===Can I see the camp layout?===<br />
We're working on this at the moment. Some initial information can be found at: [[Location]].<br />
<br />
You can see the site map at [http://map.emfcamp.org/ map.emfcamp.org]. Please note that this is still in early stages of development; we know it is slow and has bugs, don't worry about reporting them. All layout is still subject to change.<br />
<br />
===Is there parking available?===<br />
Yes. Parking tickets are on sale with tickets. Please note the car park is not adjacent to the site, but there will be a shuttle. You will not be able to drive up to or onto the site to drop anything off.<br />
<br />
If you don't yet know whether you will be bringing a car, you can buy your event ticket now and buy a parking ticket at a later date (deadline to be announced, probably early August).<br />
<br />
Parking tickets are not required for motorcycles.<br />
<br />
===Can I bring my camper van?===<br />
We have limited parking for camper vans - you can buy a ticket for £30 through our tickets site. These tickets include a parking ticket for the towing car in the car park.<br />
<br />
===Will there be Internet access?===<br />
Yes, we are provisioning onsite high speed wifi and wired access (direct to your tent!), see [[Network]].<br />
<br />
===Can I make a fire, or bring my own BBQ?===<br />
<br />
Fires on the ground are strictly prohibited. Please adhere to this requirement of both the landowner and health and safety.<br />
<br />
Barbecues must be used off the ground to reduce fire risk and prevent damaging the ground. If you have a raised fire pit this is also acceptable.<br />
<br />
Foraging for wood on the site is not permitted according to the terms of our contract with the landowners. Please bring your own fuel to site.<br />
<br />
===I see a lake on the satellite image. Can I do X in it?===<br />
<br />
The lake and brook are out of bounds by order of the site owner!<br />
<br />
===What about medical cover?===<br />
<br />
We will have our our own lovely volunteer first aiders + SJA coverage.<br />
<br />
==Getting Involved==<br />
===What will I be able to do?===<br />
We're planning a full line up of speakers and workshops as well as awesome things around the site. We will also be supporting community organised 'villages' and looking for volunteers to help run the event.<br />
<br />
===What is a 'Village'?===<br />
Villages are camps organised around a theme, it could be anything, but is often a location or a topic (e.g. lock-picking). By organising villages ahead of time we can help provide better equipment (e.g. large tents to use) as well as making sure that they have an area ahead of time. If you want to find out more about villages, join one or see what villages have already been organised check the [[Villages]] page.<br />
<br />
===How do I give a talk/run a workshop?===<br />
<br />
The [https://www.emfcamp.org/cfp Call for Participation] is now open, so if you want to give a talk or run a workshop, please fill in the form soon. We really want a wide variety of topics from as diverse a group of people as we can, so don't be shy! If you've missed the CfP then don't worry, there will be [http://en.wikipedia.org/wiki/Lightning_talk lightning talk] sessions and villages are welcome to run their own talks and workshops.<br />
<br />
===Would people be interested in a talk on X?===<br />
Yes. There are obviously a few caveats on that but they're covered in the [https://www.emfcamp.org/cfp Call for Participation]<br />
<br />
===I want to bring/make something awesome, can you help?===<br />
Hopefully. We have a limited budget to put towards making the camp amazing and we want to share it with those of you who will bring awesome things. At EMF2012 we had a giant hammock, floating LEDs, a wooden dinosaur and 'EMF' written in 5m tall steel letters. If there's something amazing that you'd like to make and bring along but need some help buying materials we'll be opening our submissions process soon.<br />
<br />
===How do I volunteer?===<br />
The easiest way is to tick the 'interested in volunteering' box when you buy your ticket (sorry volunteers still need a ticket). If you missed it don't worry you can volunteer at any time by signing in and ticking the box. Once you've signed up to volunteer we'll get in contact with you closer to the time to organise shifts.<br />
<br />
==Villages==<br />
=== Can we reserve a location for our village? ===<br />
No, not really. What is possible is to obtain an advisory lock on a certain general area, but there will be no reservation system in place and if your village shows up late the spot may be taken.<br />
<br />
=== When can I build my village? ===<br />
we are working on answering that question very soon. This mainly relies on toilets, water and power being availible. We will post some information later on the [[Villages|village page]] in the wiki.<br />
<br />
=== Our village wants to rent a tent, is that possible? ===<br />
We are working on that, information about that will be added to [[Villages|the wiki]] when availible. <br />
<br />
=== Our village is planning a cool workshop / performance / ..., can the program mention it? ===<br />
We'd really like to do that! Please [mailto:contact@emfcamp.org get in touch].<br />
<br />
=== Our village is really big, does that need special planning? ===<br />
Probably: yes. Please contact general@lists.emfcamp.org, the single point of contact for all things villages concern so far.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Villages:Women_and_non-binary&diff=1708Villages:Women and non-binary2014-08-15T11:31:12Z<p>Jonty: </p>
<hr />
<div>{{Village<br />
|Name=Women and non-binary village<br />
|Description=Village for women and non-binary people to camp, cook and chat together and feel a bit more secure.<br />
|Contact=Drcable<br />
|Activities=<br />
<br />
* Campingolely<br />
* cooking<br />
* chatting<br />
* Possibly some talks and/or workshops<br />
}}<br />
This is a village for women and non-binary people to chat, camp and cook together and people identifying solely as men (be they cis or trans) are asked to respect this. The idea behind this village is to offer a space where people who face some of the same issues can meet with each other. Presentation will not be policed and it goes without saying that trans women are welcome. While we ask you to respect the personal space of people using this village, intention and behaviours are what counts. We recognise that the campsite is limited in terms of space and privacy. If you accidentally wander in, that's not a problem, but if you are asked to leave, please take that request seriously (as you would with any village). <br />
<br />
The village will be identified with a sign and some bunting – details of this are being finalised and will be posted here.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Talk:Villages:ElectroMagneticPhone&diff=1377Talk:Villages:ElectroMagneticPhone2014-08-06T13:43:49Z<p>Jonty: Jonty moved page Talk:Villages:ElectroMagneticPhone to Talk:Villages:FieldPhone: PUNNING NAME++</p>
<hr />
<div>#REDIRECT [[Talk:Villages:FieldPhone]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Talk:Villages:FieldPhone&diff=1376Talk:Villages:FieldPhone2014-08-06T13:43:49Z<p>Jonty: Jonty moved page Talk:Villages:ElectroMagneticPhone to Talk:Villages:FieldPhone: PUNNING NAME++</p>
<hr />
<div>== SIP ==<br />
<br />
I've been working on [[Telephony]] and phones for orga, do you want to interconnect with this or maybe even take it over? It's just an Asterisk instance and a slew of Cisco IP phones. --[[User:Davidc|Davidc]] ([[User talk:Davidc|talk]]) 08:08, 10 July 2014 (UTC)</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Villages:ElectroMagneticPhone&diff=1375Villages:ElectroMagneticPhone2014-08-06T13:43:49Z<p>Jonty: Jonty moved page Villages:ElectroMagneticPhone to Villages:FieldPhone: PUNNING NAME++</p>
<hr />
<div>#REDIRECT [[Villages:FieldPhone]]</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Villages:FieldPhone&diff=1374Villages:FieldPhone2014-08-06T13:43:49Z<p>Jonty: Jonty moved page Villages:ElectroMagneticPhone to Villages:FieldPhone: PUNNING NAME++</p>
<hr />
<div>{{Village<br />
|Name=Field Phone<br />
|Description=We will be operating an attendee phone network.<br />
<br />
We are basing a lot of our plans off the experiences of Papa Legba at Burning Man and EventPhone.<br />
|Activities=Lots of SIP, GSM etc etc<br />
|Contact=Kevinprince<br />
}}<br />
More coming soon</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Workshops&diff=1325Workshops2014-08-04T10:48:11Z<p>Jonty: ARGH THIS IS NOT THE CFP</p>
<hr />
<div>{{link-banner}}<br />
== Electromagnetic Field 2014 Workshops ==<br />
<br />
Workshops are interactive events where you are expected to participate, learn, teach, and have a lot of fun. They range from lockpicking, soldering, debating, pentesting to robotics, making chiptunes and more.<br />
<br />
=== Planned workshops ===<br />
<br />
No workshops have been confirmed yet, watch this page for updates on this topic!<br />
<br />
=== Want to give a workshop? ===<br />
<br />
If you are interested in giving a workshop, please fill in the '''[https://www.emfcamp.org/cfp Call for Participation]'''.<br />
<br />
=== Workshops we'd like to see (suggestions) ===<br />
* More blacksmithery (as per 2012)<br />
* How to make a Klein bottle<br />
* Green woodworking ([[http://www.mallinson.co.uk/courses.html this sort of thing]])<br />
* The headhacking guy<br />
* Stained glass<br />
* Knitting<br />
* Jewellery making (silver clay, etc.)<br />
* Stop motion (with lego or hand made puppets)<br />
*</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Villages&diff=1316Villages2014-08-04T10:06:19Z<p>Jonty: </p>
<hr />
<div>__NOTOC__ __NOEDITSECTION__<br />
{{link-banner}}<br />
[[File:Ohm_villages.jpg|thumb|300px|Villages at OHM 2013]]<br />
If you've never been to an event like Electromagnetic Field, the concept of villages might be new to you. Villages are camps within EMF run by attendees. They're organised around a theme, often a location or a topic (e.g. lock-picking). Many villages organise their own workshops or talks for other volunteers to attend. And of course, share all the fun together!<br />
<br />
By organising villages ahead of time we, can '''help provide better equipment''' (e.g. large tents to use), as well as '''allocating a location'''. You can bring a large tent to use as a gathering place, somewhere to run workshops, or somewhere to house your giant robot. We can provide power and a wired internet connection to your village.<br />
<br />
If you have any questions about villages drop an email to [mailto:villages@emfcamp.org villages@emfcamp.org], or [[IRC|drop into our IRC channel]].<br />
<br />
== List of Villages==<br />
<br />
{{#ask: [[Category:Village]]<br />
| ?Name<br />
| ?Description<br />
}}<br />
<br />
(This list is automatically updated from villages registered on this wiki. It takes a little while to update.)<br />
<br />
== Register a Village ==<br />
<br />
To register your village, enter a short name for it below. You must be logged in to the wiki to register a village.<br />
<br />
{{#forminput:form=Village|query string=namespace=Villages|button text=Create Village}}<br />
If you have any issues creating your village, get in touch with us at [mailto:villages@emfcamp.org villages@emfcamp.org]. We're happy to help out.<br />
<br />
==Village Tent Rental==<br />
<br />
We now have the ability to provide marquees and furniture for your village at-cost. [[Villages/Tents_Rental|You can find the price list here]].<br />
<br />
These will be set up and taken down for you.<br />
<br />
If you would like to hire one, contact [mailto:crypt@emfcamp.org crypt@emfcamp.org]<br />
<br />
== FAQ ==<br />
If you are planning a village, you might want to check out [[FAQ#Villages|Villages section of the FAQ]].</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Villages&diff=1315Villages2014-08-04T10:05:47Z<p>Jonty: </p>
<hr />
<div>__NOTOC__ __NOEDITSECTION__<br />
{{link-banner}}<br />
[[File:Ohm_villages.jpg|thumb|300px|Villages at OHM 2013]]<br />
If you've never been to an event like Electromagnetic Field, the concept of villages might be new to you. Villages are camps within EMF run by attendees. They're organised around a theme, often a location or a topic (e.g. lock-picking). Many villages organise their own workshops or talks for other volunteers to attend. And of course, share all the fun together!<br />
<br />
By organising villages ahead of time we, can '''help provide better equipment''' (e.g. large tents to use), as well as '''allocating a location'''. You can bring a large tent to use as a gathering place, somewhere to run workshops, or somewhere to house your giant robot. We can provide power and a wired internet connection to your village.<br />
<br />
If you have any questions about villages drop an email to [mailto:villages@emfcamp.org villages@emfcamp.org], or [[IRC|drop into our IRC channel]].<br />
<br />
== List of Villages==<br />
<br />
{{#ask: [[Category:Village]]<br />
| ?Name<br />
| ?Description<br />
}}<br />
<br />
(This list is automatically updated from villages registered on this wiki. It takes a little while to update.)<br />
<br />
== Register a Village ==<br />
<br />
To register your village, enter a short name for it below. You must be logged in to the wiki to register a village.<br />
<br />
{{#forminput:form=Village|query string=namespace=Villages|button text=Create Village}}<br />
If you have any issues creating your village, get in touch with us at [mailto:villages@emfcamp.org villages@emfcamp.org]. We're happy to help out.<br />
<br />
==Village Tent Rental==<br />
<br />
We now have the ability to provide marquees and furniture for your village at-cost. [[Villages/Tents_Rental|You can find the price list here]].<br />
<br />
These should come ready set up when you arrive on site.<br />
<br />
If you would like to hire one, contact [mailto:crypt@emfcamp.org crypt@emfcamp.org]<br />
<br />
== FAQ ==<br />
If you are planning a village, you might want to check out [[FAQ#Villages|Villages section of the FAQ]].</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=FAQ&diff=884FAQ2014-07-07T18:23:42Z<p>Jonty: /* Our village is planning a cool workshop / performance / ..., can the program mention it? */</p>
<hr />
<div>{{link-banner}}<br />
This is a work in progress. Keep checking for updates.<br />
<br />
==General==<br />
===Who are you?===<br />
Electromagnetic Field is run by a non-profit organisation and produced entirely by volunteers. We are members of well-known hackerspaces and other organisations. Get in touch if you want to join us in making this happen.<br />
<br />
===Why are you doing this?===<br />
There now are dozens of hackerspaces and makerspaces in the UK and across Europe, and countless other communities of craftsmen, artists, designers, engineers who are interested in the same DIY ethic; but they have few opportunities to all meet up. Most events catering to these communities are small regional conferences and often focused on very specific themes.<br />
<br />
We want to change that :)<br />
<br />
===Why Milton Keynes?===<br />
We looked at a fair number of candidate sites. The site we ended up with was the best candidate for a number of reasons:<br />
* It comes at a comparably low price (some of the candidate sites we looked at asked for tens of thousands of £££.)<br />
* It has great transport links to much of the UK (both roads and trains.)<br />
* It is close(ish) to a few data centres and high speed Internet uplinks.<br />
* We were there last time and it seemed to work well<br />
Bonus: it is very close to Bletchley Park :)<br />
<br />
===How big is it?===<br />
<br />
In 2012, we had an attendance limit of 500 and fully sold out. This year we are expecting around 1,200 people. Buy your ticket early to avoid disappointment.<br />
<br />
==Ticket Sales==<br />
===How can I get a ticket?===<br />
Tickets are on sale from our web site here:<br />
<br />
'''https://www.emfcamp.org/tickets/choose'''<br />
<br />
This time there will be no day tickets and camp tickets are likely to sell out in advance.<br />
<br />
===How much does it cost?===<br />
Adult tickets are currently £105. There are tickets available for under-16s at a lower price (accompanied by an adult). Children under 5 can attend for free.<br />
<br />
If you have a Camper van you will need a Camper van ticket. <br />
<br />
If you want to bring a car you'll also need a car parking ticket.<br />
<br />
You can pay by bank transfer (in pounds sterling or Euros), a one-time direct debit (in pounds sterling or Euros), or by credit or debit card via Stripe (which charges a small fee).<br />
<br />
===Can I get a day ticket?===<br />
Sorry, EMF 2012 was sold to capacity and we found that the day tickets prevented people from attending the whole event. For this reason, we can only offer tickets for the whole event. You are welcome to only come to one day, or to stay off-site and attend only during the days, but you will need a weekend ticket.<br />
<br />
===Can I get a family ticket?===<br />
Unfortunately, as every attendee including children counts towards our capacity limit, we are unable to offer family or group tickets. We have however already discounted the child ticket prices by 60% which is as far as the budget allows.<br />
<br />
===Will I be able to turn up and buy a ticket?===<br />
It is unlikely that any tickets will remain by the time of the event. Watch this space.<br />
<br />
===Do volunteers pay for their ticket?===<br />
Everyone is expected to buy a ticket, including people in the organising team and all volunteers. <br />
<br />
===Is there an age limit?===<br />
We encourage children and young people to attend. We are planning specific activities for children as well as daycare facilities, and will confirm more details nearer to the time.<br />
<br />
However there are a number of things to bear in mind:<br />
* Children under the age of 14 must be accompanied by an adult at all times.<br />
* There will be dangerous things on site, but they will be clearly marked.<br />
* Licensed alcohol sales are only for people of age 18 and over. Bar staff will ask for ID.<br />
<br />
===Can't enter the transaction reference?===<br />
If you are having trouble entering the transaction reference into your online banking, just remove the hyphen. Some banks don't like it and don't tell you.<br />
<br />
===Do you have a Code of Conduct?===<br />
Yes, please see [https://www.emfcamp.org/code-of-conduct Code of conduct]. If you buy a ticket you are agreeing to abide by this.<br />
<br />
===What terms and conditions apply to ticket sales and attendance?===<br />
Please see our [https://www.emfcamp.org/pay/terms terms] page.<br />
<br />
===Can I pay more? TAKE MY MONEY!===<br />
<br />
If you can afford it and wish to help support the event financially by paying a bit more for your ticket, you can buy a Supporter ticket. We're a non-profit event and so the money will go towards making the event even more awesome.<br />
<br />
==Planning your Attendance==<br />
===Where is it? How can I get there?===<br />
Refer to [[Location]]. '''NOTE: We have moved!''' It's only a few miles down the road, but please don't go to the old site!<br />
<br />
===When can I arrive? When do I have to leave by?===<br />
The site will open to ticket holders at 10:00 Friday morning.<br />
<br />
All ticket holders must leave the site by 12:00 Monday.<br />
<br />
We will be there before and afterwards setting up and packing up, if you want to help with this please let us know and we can make arrangements. It's worth noting outside these times we can't guarantee availability of toilets/water/electricity/internet etc.<br />
<br />
Have a look at our Timeline for an updated summary.<br />
<br />
===When do things kick off?===<br />
The talks and workshops will begin after lunch on Friday, although people will be setting up earlier in the day. You can arrive from 10am.<br />
<br />
Talks and workshops run daily through to the evening, although we expect villages will be doing things late into the night!<br />
<br />
===What should I bring?===<br />
Please take a look at our [[Packing List]] for information on what you should and shouldn't bring.<br />
<br />
===Will there be food?===<br />
We appreciate we didn't do well at this last time. This year we have lined up multiple food stalls, hopefully catering to all your needs. Initial details are at [[Food]]<br />
<br />
===Will there be a bar?===<br />
Yes, we'll be running a volunteer-staffed licensed bar selling beer and wine, as well as soft drinks and the hacker energy drink Club Mate. Far from the usual crap festival beer, we will be serving real ale from local breweries with all profits going towards making the next iteration of Electromagnetic Field more awesome.<br />
<br />
The bar on site opening hours are subject to licensing which will be finalised soon.<br />
<br />
By the camping areas there will also be push taps of drinking water available for free.<br />
<br />
===Can I bring pets?===<br />
Sorry, animals (except registered assistance dogs) are not allowed.<br />
<br />
===Can I smoke?===<br />
Smoking is not allowed in any of the event tents or in the food/bar area. Elsewhere, please be considerate and very careful to extinguish your cigarettes to avoid setting the dry grass on fire. Please make sure cigarette butts are disposed of in rubbish bins rather than just thrown on the ground as the site is used by livestock at other times of the year, and it's a pain for the clean up crew to pick them up after the camp is over!<br />
<br />
===Can I bring X/Y/Z?===<br />
tl;dr Probably<br />
<br />
Please let us know if it's going to be large/use a lot of power/be noisy or anything else you think we should know. We don't plan on stopping people bringing the latest cool laser helmet for shark 3d printer arduino powered UAV thing, but we need to plan for it. Note that access to the site is several hundred metres from the carpark and you will not be able to drive up to the site.<br />
<br />
Things prohibited by our contract: balloons, sky lanterns and the like.<br />
<br />
===Can I leave and re-enter?===<br />
Your wristband will allow re-admittance, but the site is gated and we will be trying to restrict movements to daylight hours. In reality this is unlikely to be a problem, but please speak to us if you have any special requirements. The farm gate is locked overnight and would require a volunteer to come up to let you out.<br />
<br />
Please note that it is a condition of our contract that we don't allow you to roam the farm. Apart from anything else, there is likely to be heavy farm machinery in operation. For this reason, the entire event area is fenced off. We can shuttle you to the parking area, from where you may drive off the site or be collected.<br />
<br />
==Camp Infrastructure==<br />
===Can I see the camp layout?===<br />
We're working on this at the moment. Some initial information can be found at: [[Location]].<br />
<br />
You can see the site map at [http://map.emfcamp.org/ map.emfcamp.org]. Please note that this is still in early stages of development; we know it is slow and has bugs, don't worry about reporting them. All layout is still subject to change.<br />
<br />
===Is there parking available?===<br />
Yes. Parking tickets are on sale with tickets. Please note the car park is not adjacent to the site, but there will be a shuttle. You will not be able to drive up to or onto the site to drop anything off.<br />
<br />
If you don't yet know whether you will be bringing a car, you can buy your event ticket now and buy a parking ticket at a later date (deadline to be announced, probably early August).<br />
<br />
Parking tickets are not required for motorcycles.<br />
<br />
===Can I bring my camper van?===<br />
We have limited parking for camper vans - you can buy a ticket for £30 through our tickets site. These tickets include a parking ticket for the towing car in the car park.<br />
<br />
===Will there be Internet access?===<br />
Yes, we are provisioning onsite high speed wifi and wired access (direct to your tent!), see [[Network]].<br />
<br />
===Can I make a fire, or bring my own BBQ?===<br />
<br />
Open fire is strictly prohibited except in the main fire pit. Please adhere to this requirement of both the landowner and health and safety.<br />
<br />
Barbecues must be used off the ground to reduce fire risk and prevent damaging the ground.<br />
<br />
Foraging for wood on the site is not permitted according to the terms of our contract with the landowners. Please bring your own fuel to site.<br />
<br />
===I see a lake on the satellite image. Can I do X in it?===<br />
<br />
The lake and brook are out of bounds by order of the site owner!<br />
<br />
===What about medical cover?===<br />
<br />
We will have our our own lovely volunteer first aiders + SJA coverage.<br />
<br />
==Getting Involved==<br />
===What will I be able to do?===<br />
We're planning a full line up of speakers and workshops as well as awesome things around the site. We will also be supporting community organised 'villages' and looking for volunteers to help run the event.<br />
<br />
===What is a 'Village'?===<br />
Villages are camps organised around a theme, it could be anything, but is often a location or a topic (e.g. lock-picking). By organising villages ahead of time we can help provide better equipment (e.g. large tents to use) as well as making sure that they have an area ahead of time. If you want to find out more about villages, join one or see what villages have already been organised check the [[Villages]] page.<br />
<br />
===How do I give a talk/run a workshop?===<br />
<br />
The [https://www.emfcamp.org/cfp Call for Participation] is now open, so if you want to give a talk or run a workshop, please fill in the form soon. We really want a wide variety of topics from as diverse a group of people as we can, so don't be shy! If you've missed the CfP then don't worry, there will be [http://en.wikipedia.org/wiki/Lightning_talk lightning talk] sessions and villages are welcome to run their own talks and workshops.<br />
<br />
===Would people be interested in a talk on X?===<br />
Yes. There are obviously a few caveats on that but they're covered in the [https://www.emfcamp.org/cfp Call for Participation]<br />
<br />
===I want to bring/make something awesome, can you help?===<br />
Hopefully. We have a limited budget to put towards making the camp amazing and we want to share it with those of you who will bring awesome things. At EMF2012 we had a giant hammock, floating LEDs, a wooden dinosaur and 'EMF' written in 5m tall steel letters. If there's something amazing that you'd like to make and bring along but need some help buying materials we'll be opening our submissions process soon.<br />
<br />
===How do I volunteer?===<br />
The easiest way is to tick the 'interested in volunteering' box when you buy your ticket (sorry volunteers still need a ticket). If you missed it don't worry you can volunteer at any time by signing in and ticking the box. Once you've signed up to volunteer we'll get in contact with you closer to the time to organise shifts.<br />
<br />
==Villages==<br />
=== Can we reserve a location for our village? ===<br />
No, not really. What is possible is to obtain an advisory lock on a certain general area, but there will be no reservation system in place and if your village shows up late the spot may be taken.<br />
<br />
=== When can I build my village? ===<br />
we are working on answering that question very soon. This mainly relies on toilets, water and power being availible. We will post some information later on the [[Villages|village page]] in the wiki.<br />
<br />
=== Our village wants to rent a tent, is that possible? ===<br />
We are working on that, information about that will be added to [[Villages|the wiki]] when availible. <br />
<br />
=== Our village is planning a cool workshop / performance / ..., can the program mention it? ===<br />
We'd really like to do that! Please [mailto:contact@emfcamp.org get in touch].<br />
<br />
=== Our village is really big, does that need special planning? ===<br />
Probably: yes. Please contact general@lists.emfcamp.org, the single point of contact for all things villages concern so far.</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Villages&diff=883Villages2014-07-07T18:21:57Z<p>Jonty: </p>
<hr />
<div>__NOTOC__ __NOEDITSECTION__<br />
If you've never been to an event like Electromagnetic Field the concept of villages might be new to you. Villages are camps within EMF run by attendees. They're organised around a theme, often a location or a topic (e.g. lock-picking). Many villages organise their own workshops and lectures for other volunteers to attend. And of course, share all the fun together!<br />
<br />
By organising villages ahead of time we, can '''help provide better equipment''' (e.g. large tents to use), as well as '''allocating a location'''. You can bring a large tent to use as a gathering place, somewhere to run workshops, or somewhere to house your giant robot.<br />
<br />
If you have any questions about villages drop an email to [mailto:villages@emfcamp.org villages@emfcamp.org], or [[IRC|drop into our IRC channel]].<br />
<br />
== List of Villages==<br />
<br />
{{#ask: [[Category:Village]]<br />
| ?Name<br />
| ?Description<br />
}}<br />
<br />
(This list is automatically updated from villages registered on this wiki. It takes a little while to update.)<br />
<br />
== Register a Village ==<br />
<br />
To register your village, enter a short name for it below. You must be logged in to the wiki to register a village.<br />
<br />
{{#forminput:form=Village}}<br />
If you have any issues creating your village, get in touch with us at [mailto:villages@emfcamp.org villages@emfcamp.org]. We're happy to help out.<br />
<br />
==Village Tent Rental==<br />
<br />
We might have rental tents. Further information coming shortly!<br />
<br />
For information, please contact [mailto:general@lists.emfcamp.org general@lists.emfcamp.org].<br />
<br />
== FAQ ==<br />
If you are planning a village, you might want to check out [[FAQ#Villages|Villages section of the FAQ]].</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Villages&diff=882Villages2014-07-07T18:21:12Z<p>Jonty: </p>
<hr />
<div>__NOTOC__ __NOEDITSECTION__<br />
If you've never been to an event like Electromagnetic Field the concept of villages might be new to you. Villages are camps within EMF run by attendees. They're organised around a theme, often a location or a topic (e.g. lock-picking). Many villages organise their own workshops and lectures for other volunteers to attend. And of course, share all the fun together!<br />
<br />
By organising villages ahead of time we, can '''help provide better equipment''' (e.g. large tents to use), as well as '''allocating a location'''. You can bring a large tent to use as a gathering place, somewhere to run workshops, or somewhere to house your giant robot.<br />
<br />
If you have any questions about villages drop an email to [mailto:villages@emfcamp.org villages@emfcamp.org], or [IRC|drop into our IRC channel].<br />
<br />
== List of Villages==<br />
<br />
{{#ask: [[Category:Village]]<br />
| ?Name<br />
| ?Description<br />
}}<br />
<br />
(This list is automatically updated from villages registered on this wiki. It takes a little while to update.)<br />
<br />
== Register a Village ==<br />
<br />
To register your village, enter a short name for it below. You must be logged in to the wiki to register a village.<br />
<br />
{{#forminput:form=Village}}<br />
If you have any issues creating your village, get in touch with us at [mailto:villages@emfcamp.org villages@emfcamp.org]. We're happy to help out.<br />
<br />
==Village Tent Rental==<br />
<br />
We might have rental tents. Further information coming shortly!<br />
<br />
For information, please contact general@lists.emfcamp.org.<br />
<br />
== FAQ ==<br />
If you are planning a village, you might want to check out [[FAQ#Villages|Villages section of the FAQ]].</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Villages&diff=881Villages2014-07-07T18:20:45Z<p>Jonty: </p>
<hr />
<div>__NOTOC__ __NOEDITSECTION__<br />
If you've never been to an event like Electromagnetic Field the concept of villages might be new to you. Villages are camps within EMF run by attendees. They're organised around a theme, often a location or a topic (e.g. lock-picking). Many villages organise their own workshops and lectures for other volunteers to attend. And of course, share all the fun together!<br />
<br />
By organising villages ahead of time we, can '''help provide better equipment''' (e.g. large tents to use), as well as '''allocating a location'''. You can bring a large tent to use as a gathering place, somewhere to run workshops, or somewhere to house your giant robot.<br />
<br />
If you have any questions about villages drop an email to [mailto:villages@emfcamp.org villages@emfcamp.org], or [[IRC drop into our IRC channel]].<br />
<br />
== List of Villages==<br />
<br />
{{#ask: [[Category:Village]]<br />
| ?Name<br />
| ?Description<br />
}}<br />
<br />
(This list is automatically updated from villages registered on this wiki. It takes a little while to update.)<br />
<br />
== Register a Village ==<br />
<br />
To register your village, enter a short name for it below. You must be logged in to the wiki to register a village.<br />
<br />
{{#forminput:form=Village}}<br />
If you have any issues creating your village, get in touch with us at [mailto:villages@emfcamp.org villages@emfcamp.org]. We're happy to help out.<br />
<br />
==Village Tent Rental==<br />
<br />
We might have rental tents. Further information coming shortly!<br />
<br />
For information, please contact general@lists.emfcamp.org.<br />
<br />
== FAQ ==<br />
If you are planning a village, you might want to check out [[FAQ#Villages|Villages section of the FAQ]].</div>Jontyhttps://wiki.emfcamp.org/2014/w/index.php?title=Teams&diff=428Teams2014-03-10T22:21:00Z<p>Jonty: </p>
<hr />
<div>{| class="wikitable sortable"<br />
! Team<br />
! Description<br />
! Lead<br />
! Deputy Lead(s)<br />
|-<br />
| [[Team:Admin]]<br />
| Top-level organisation, licensing, site planning<br />
| [[User:Russ]]<br />
| [[User:Jonty]]<br />
|-<br />
| [[Team:Finance]]<br />
| Dealing with the money<br />
| [[User:Russ]]<br />
|<br />
|-<br />
| [[Team:Power]]<br />
| All things power<br />
| [[User:Benny]]<br />
| Will H<br />
|-<br />
| [[Team:NOC]]<br />
| Networking<br />
| Will H<br />
|<br />
|-<br />
| [[Team:Web]]<br />
| Web sites, ticket sales, volunteering, and CfP systems<br />
| [[User:ms7821|Mark]]<br />
| [[User:JasperWallace]] (probably?)<br />
|-<br />
| [[Team:Content]]<br />
| Organising talks/workshops/etc<br />
| [[User:Jonty]]<br />
|<br />
|-<br />
| [[Team:Bar]]<br />
| Booze, and such<br />
| [[User:Russ]]<br />
|<br />
|-<br />
| [[Team:First Aid]]<br />
| Making sure we don't kill ourselves<br />
| Oni<br />
|<br />
|-<br />
| [[Team:Catering]]<br />
| Organising food providers<br />
| Nick<br />
| [[User:JasperWallace]] (maybe?)<br />
|-<br />
| [[Team:InfoDesk]]<br />
| Providing information during the event<br />
| ?<br />
|<br />
|-<br />
| [[Team:Volunteering]]<br />
| Managing volunteers across all stages<br />
| ?<br />
| Nick/Lyndsey/Kate<br />
|-<br />
| [[Team:Spawn]]<br />
| Managing the kids area, activities, and childminding<br />
| ?<br />
|<br />
|-<br />
| [[Team:AV]]<br />
| Audio. Video. Streaming. That kind of thing.<br />
| ?<br />
|<br />
|-<br />
| [[Team:Shiny]]<br />
| Site decoration, lights, installations. Shiny things.<br />
| ?<br />
| [[User:Jonty]]<br />
|-<br />
| [[Team:Badge]]<br />
| Badge building, and infrastructure.<br />
| LWK<br />
| Bob/[[User:Jonty]]<br />
|}</div>Jonty