Assuming the NRG is just a single session ISO CD image, you can just remove the first few kb with dd from Terminal.app
Code:
dd if=image.nrg of=cdrom.iso bs=512 skip=600
Sunday, November 13, 2011
Friday, November 11, 2011
Game states
final int STATE_XBEE_INIT = 0;
final int STATE_PLAYER_LIST = 1;
final int STATE_LEVEL_SELECT = 2;
final int STATE_PLAY = 3;
final int STATE_HIGHSCORE = 4;
final int STATE_PLAYER_LIST = 1;
final int STATE_LEVEL_SELECT = 2;
final int STATE_PLAY = 3;
final int STATE_HIGHSCORE = 4;
Lag test
else if (mode == 2) {
println("We can test the lag now.");
players[0].xpansProx[0].broadcastProxConfig(1500);
mode++;
}
else {// done
initLevel(players, "levels/03-nomoremosquitos.xml");
for (int s=4; s<8; s++) { // Send an arbitrary step to the patches
println("Sending step "+s+" at time "+millis());
for (int i=0; i
delay(500);
}
}
}
println("We can test the lag now.");
players[0].xpansProx[0].broadcastProxConfig(1500);
mode++;
}
else {// done
initLevel(players, "levels/03-nomoremosquitos.xml");
for (int s=4; s<8; s++) { // Send an arbitrary step to the patches
println("Sending step "+s+" at time "+millis());
for (int i=0; i
delay(500);
}
}
}
Shut off buzzing by hand, for player 1
// shut off glove buzzer
players[0].xpansVibe[0].broadcastVibe(0);
// shut off patch buzzer
Step shutoff = new Step(false, false, false, false, false);
players[0].xpansProx[0].broadcastStep(0, shutoff, shutoff, shutoff, shutoff);
for player 2, just do it for players[1]
players[0].xpansVibe[0].broadcastVibe(0);
// shut off patch buzzer
Step shutoff = new Step(false, false, false, false, false);
players[0].xpansProx[0].broadcastStep(0, shutoff, shutoff, shutoff, shutoff);
for player 2, just do it for players[1]
Tuesday, November 8, 2011
PANs
Player 1 PANs:
1001: two proximity sensors, one base -- bidirectional.
Node Identifier: P1_PROX1
base ID: 0
end device IDs: 1, 2
1002: two proximity sensors, one base -- bidirectional.
Node Identifier: P1_PROX2
base ID: 0
end device IDs: 3, 4
1003: two vibes, one base
Node Identifier: P1_VIBE
base ID: 0
end device IDs: 5, 6
1004: two accelerometers, one base -- incoming only.
Node Identifier: P1_ACCEL
base ID: 0
end device IDs: 7, 8
Player 2 PANs:
2001: two proximity sensors, one base -- bidirectional.
Node Identifier: P2_PROX1
base ID: 0
end device IDs: 9, 10
2002: two proximity sensors, one base -- bidirectional.
Node Identifier: P2_PROX2
base ID: 0
end device IDs: 11, 12
2003: two vibes, one base
Node Identifier: P2_VIBE
base ID: 0
end device IDs: 13, 14
2004: two accelerometers, one base -- incoming only.
Node Identifier: P2_ACCEL
base ID: 0
end device IDs: 15, 16
One bottleneck is the baud rate between the base Xbee and the computer. This should be cranked up to 115200. The baud rate between the arduinos and the endpoint Xbees can remain at 9600.
1001: two proximity sensors, one base -- bidirectional.
Node Identifier: P1_PROX1
base ID: 0
end device IDs: 1, 2
1002: two proximity sensors, one base -- bidirectional.
Node Identifier: P1_PROX2
base ID: 0
end device IDs: 3, 4
1003: two vibes, one base
Node Identifier: P1_VIBE
base ID: 0
end device IDs: 5, 6
1004: two accelerometers, one base -- incoming only.
Node Identifier: P1_ACCEL
base ID: 0
end device IDs: 7, 8
Player 2 PANs:
2001: two proximity sensors, one base -- bidirectional.
Node Identifier: P2_PROX1
base ID: 0
end device IDs: 9, 10
2002: two proximity sensors, one base -- bidirectional.
Node Identifier: P2_PROX2
base ID: 0
end device IDs: 11, 12
2003: two vibes, one base
Node Identifier: P2_VIBE
base ID: 0
end device IDs: 13, 14
2004: two accelerometers, one base -- incoming only.
Node Identifier: P2_ACCEL
base ID: 0
end device IDs: 15, 16
One bottleneck is the baud rate between the base Xbee and the computer. This should be cranked up to 115200. The baud rate between the arduinos and the endpoint Xbees can remain at 9600.
Data packets for xbees
Message/Packet types:
1: from base to proximity patches telling them it’s the beginning of a turn. [5 BYTES]
2: from prox. patches to base providing sensor readings. [6 BYTES]
3: from base to gloves telling them what intensity to vibrate. [2 BYTES]
4: from accelerometer anklets to base providing sensor readings. [5 BYTES]
5: Config. from base to proximity patches. [3 BYTES]
6: Ack. of configuration messages, send from prox. patches to base in response to config. [4 BYTES]
7: Messages from gloves to base, for button presses on gloves, UI control. [3 BYTES]
More Info about Packets
2fake: data simulation packet outgoing of patch:
“sent” approximately every 50 ms, with a small percentage of dropped packets:
time (ms)
player #: 0 or 1
patch #: 0-3
touched: 0-1
prox: 0-1028
4fake: data simulation packet outgoing of accelerometer:
set every 50 ms, with a small percentage of dropped packets:
player#
patch#
accel: 1-255
2real: real packet outgoing of patch
sent by patch arduino software
every 50 ms
highest prox reading of interval
7real: real packet outgoing of patch: button press
4real: real packet outgoing of accelerometer
sent by anklet arduino software
every 50 ms
highest accel. reading of interval
Packet structure
Packet structures, by byte:
Type #1: Base to Prox
0: Packet type
1: Step number (high order bits)
2: Step number (low order bits)
3: patches active this turn (4 bits) and patches active next turn (4 bits) - patch is active or not: 1 or 0
4: patches active two turns from now (4 bits) and patches active 3 turns from now (4 bits)
Type #2: Prox to Base
0: Message Type
1: Patch Address (7 bits, expect 1-4, 9-12) | touched (1 bit)
2: Step number (high order bits)
3: Step number (low order bits)
4: Proximity reading (high order bits)
5: Proximity reading (low order bits)
Type #3: Base to Gloves
0: Message Type
1: Vibe intensity (higher -> more vibration)
Type #4: Accel to Base
0: Message type
1: Patch Address (expect 7-8, 15-16)
2: X axis reading
3: Y axis reading
4: Z axis reading
Type #5: Config, base to prox
0: Message Type
1: Length of step (high order bits) - tells the patches how long each “step” will be during this level
2: Length of step (low order bits)
Type #7: Glove to Base
0: Message Type
1: Patch address (expect 5-6, 13-14)
2: Which button was touched
Button touch data is an int encoded thus:
0: no touch, or ambiguous touch that we shouldn’t react to
1: left button ONLY was touched
2: right button ONLY was touched
3: center button ONLY was touched
4: all three buttons were touched
1: from base to proximity patches telling them it’s the beginning of a turn. [5 BYTES]
2: from prox. patches to base providing sensor readings. [6 BYTES]
3: from base to gloves telling them what intensity to vibrate. [2 BYTES]
4: from accelerometer anklets to base providing sensor readings. [5 BYTES]
5: Config. from base to proximity patches. [3 BYTES]
6: Ack. of configuration messages, send from prox. patches to base in response to config. [4 BYTES]
7: Messages from gloves to base, for button presses on gloves, UI control. [3 BYTES]
More Info about Packets
2fake: data simulation packet outgoing of patch:
“sent” approximately every 50 ms, with a small percentage of dropped packets:
time (ms)
player #: 0 or 1
patch #: 0-3
touched: 0-1
prox: 0-1028
4fake: data simulation packet outgoing of accelerometer:
set every 50 ms, with a small percentage of dropped packets:
player#
patch#
accel: 1-255
2real: real packet outgoing of patch
sent by patch arduino software
every 50 ms
highest prox reading of interval
7real: real packet outgoing of patch: button press
4real: real packet outgoing of accelerometer
sent by anklet arduino software
every 50 ms
highest accel. reading of interval
Packet structure
Packet structures, by byte:
Type #1: Base to Prox
0: Packet type
1: Step number (high order bits)
2: Step number (low order bits)
3: patches active this turn (4 bits) and patches active next turn (4 bits) - patch is active or not: 1 or 0
4: patches active two turns from now (4 bits) and patches active 3 turns from now (4 bits)
Type #2: Prox to Base
0: Message Type
1: Patch Address (7 bits, expect 1-4, 9-12) | touched (1 bit)
2: Step number (high order bits)
3: Step number (low order bits)
4: Proximity reading (high order bits)
5: Proximity reading (low order bits)
Type #3: Base to Gloves
0: Message Type
1: Vibe intensity (higher -> more vibration)
Type #4: Accel to Base
0: Message type
1: Patch Address (expect 7-8, 15-16)
2: X axis reading
3: Y axis reading
4: Z axis reading
Type #5: Config, base to prox
0: Message Type
1: Length of step (high order bits) - tells the patches how long each “step” will be during this level
2: Length of step (low order bits)
Type #7: Glove to Base
0: Message Type
1: Patch address (expect 5-6, 13-14)
2: Which button was touched
Button touch data is an int encoded thus:
0: no touch, or ambiguous touch that we shouldn’t react to
1: left button ONLY was touched
2: right button ONLY was touched
3: center button ONLY was touched
4: all three buttons were touched
Wednesday, September 28, 2011
Run X-CTU with MacOS X Lion
X-CTU is the Windows software that is required to update the firmware of the XBee radios. It is not compatible with neither Linux nor Mac, but it can be used with wine - the Windows emulator.
I used Wineskin which produces standalone Mac Software packages based on wine.
First of all, get the X-CTU program from digi.com, and get wineskin for Mac.
Follow the tutorial for software with a windows installer that comes with wineskin.
Just name your wrapper X-CTU and point to the X-CTU installer from digi.com in the steps where the tutorial uses Neverball.
After clicking the advanced tab of your new wrapper, in the tools section you click "Test run application" to test your X-CTU program that you just wrapped for Mac.
You will see immediately that it complains that it cannot connect to com ports - as there are no com ports on the Mac.
We have to map the USB ports to the com ports by hand:
The port mappings for your new wrapper live under Contents/Resources/dosdevices in the wrapper we just created and should have still opened in finder (at /Users/yourusername/Applications/Wineskin/X-CTU.app).
We now create softlinks from the mac USB ports to windows com ports. Plug in your device, open terminal and go to the dosdevices folder:
cd /Users/yourusername/Applications/Wineskin/X-CTU.app/Contents/Resources/dosdevices
Look up the device location of your plugged in device, it should be /dev/tty.usbserialXXXX for an XBee on a XBee explorer connected via USB. Here, XXXX is the device ID and is different for every device.
Choose a high number for the com port, as the lower ones may be already in use by wine. I have chosen 10.
ln -s /dev/tty.usbserialXXXX com10
Kill and test run your X-CTU wrapper application again, and the complaint about the missing com ports should be gone. Add your new com port now, so that X-CTU knows it:
In the bottom panel, go to the "User Com Ports" tab. At the right, put your com port number in the box (e.g. 10) and press the "Add" button.
It now appears in the top panel, and you should be able to test/query the XBee sucessfully.
Your very own selfmade Mac version of X-CTU and your XBee should now be able to play well together.
Caveat: The com port number is forgotten by X-CTU on shutdown. So you have to go to "User Com Ports"->"Add" every time you start up your X-CTU wrapper again.
I used Wineskin which produces standalone Mac Software packages based on wine.
First of all, get the X-CTU program from digi.com, and get wineskin for Mac.
Follow the tutorial for software with a windows installer that comes with wineskin.
Just name your wrapper X-CTU and point to the X-CTU installer from digi.com in the steps where the tutorial uses Neverball.
After clicking the advanced tab of your new wrapper, in the tools section you click "Test run application" to test your X-CTU program that you just wrapped for Mac.
You will see immediately that it complains that it cannot connect to com ports - as there are no com ports on the Mac.
We have to map the USB ports to the com ports by hand:
The port mappings for your new wrapper live under Contents/Resources/dosdevices in the wrapper we just created and should have still opened in finder (at /Users/yourusername/Applications/Wineskin/X-CTU.app).
We now create softlinks from the mac USB ports to windows com ports. Plug in your device, open terminal and go to the dosdevices folder:
cd /Users/yourusername/Applications/Wineskin/X-CTU.app/Contents/Resources/dosdevices
Look up the device location of your plugged in device, it should be /dev/tty.usbserialXXXX for an XBee on a XBee explorer connected via USB. Here, XXXX is the device ID and is different for every device.
Choose a high number for the com port, as the lower ones may be already in use by wine. I have chosen 10.
ln -s /dev/tty.usbserialXXXX com10
Kill and test run your X-CTU wrapper application again, and the complaint about the missing com ports should be gone. Add your new com port now, so that X-CTU knows it:
In the bottom panel, go to the "User Com Ports" tab. At the right, put your com port number in the box (e.g. 10) and press the "Add" button.
It now appears in the top panel, and you should be able to test/query the XBee sucessfully.
Your very own selfmade Mac version of X-CTU and your XBee should now be able to play well together.
Caveat: The com port number is forgotten by X-CTU on shutdown. So you have to go to "User Com Ports"->"Add" every time you start up your X-CTU wrapper again.
Subscribe to:
Posts (Atom)