#define MAX_MESSAGE_LENGTH 20 char message[MAX_MESSAGE_LENGTH]; int message_pos;
// use to keep track of ambient light, this value is used to do basic automatic gain // control so that the demo can work in multiple ambient light conditions int ambient;
boolean wait(int milliseconds, boolean watch) { long target = millis() + milliseconds; do { gb.buttons.update(); gb.sound.updatePattern(); if (watch && any_button_pressed()) { gb.sound.playCancel(); return true; } } while (millis() < target); return false; }
void sendBit(int bit) { digitalWrite(BACKLIGHT_PIN, bit ? HIGH : LOW); delay(DELAY); }
void send(char c) { Serial.print(c); sendBit(1); // start bit for (int i=0; i<8; i++, c>>=1) sendBit(c&1); sendBit(0); // stop bit }
void send(const char * str) { while (*str) send(*str++); }
void receive() { gb.display.clear(); gb.display.println("Receiving..."); gb.backlight.automatic = false; gb.display.update(); pinMode(AMBIENTLIGHT_PIN, OUTPUT); digitalWrite(BACKLIGHT_PIN, LOW); ambient = analogRead(AMBIENTLIGHT_PIN); gb.sound.playOK(); wait(1000, false); int low = analogRead(AMBIENTLIGHT_PIN); int high = low + TRIGGER; int middle = (low + high) >> 1; message_pos = 0; while (true) { // wait for start of character while (true) { if (wait(0, true)) return;
int current = analogRead(AMBIENTLIGHT_PIN); if (current >= middle) { high = current; break; } if (current < middle) { low = current; high = low + TRIGGER; middle = (low + high) >> 1; } }
// read in the character delay(2*DELAY/3); high = analogRead(AMBIENTLIGHT_PIN); middle = (low + high) >> 1;
// stream the bytes in char c = 0; for (int i=0; i<8; i++) { delay(DELAY); int val = analogRead(AMBIENTLIGHT_PIN); if (val > middle) { c |= (1 << i); high = val; } else { low = val; } middle = (low + high) >> 1; } delay(DELAY);
// test for end of message if (c == '\n') { message[message_pos++] = 0; display_message(); return; } else if (message_pos < MAX_MESSAGE_LENGTH) message[message_pos++] = c; } }
Ingenious... to bad there is such a variation in screen quality. On my two Gamebuinos the backlights are similar, but one is ghosting like crazy, making it impossible to play games like Crabator, while on the other one contrast adjustments apparently do nothing, although the contrast level it is "stuck" at is very good and works well for all the games on the SD card.
If the Gamebuino had a microphone sound wave modulation could work, speakers are all technically the same. Well, to push it farther, you can use any speaker as a microphone too... can you read from the speaker pins if you go very low level?
I've been thinking about the speaker myself over the past few days. I'm planning to test it when I get the chance but to be honest I seriously doubt it will work. I can't see it picking up an induced field of any reasonable strength and even if it did the flyback diode used to protect the sound circuit from back-emf would shunt anything higher than the forward threshold voltage of around 0.6V (I think). Whatever was left over would then need to cross the collector-base junction of the drive transistor in order to be read by the speaker pin. I'd love to be proven wrong but I just can't see it working.
One thing that could work though is using Gamebuino in transmit-only mode. In theory the speaker could generate an oscillating field too fast to create sound but at exactly the right frequency to spoof an RFID tag, so you could open door locks that use standard ASK contact-less smart cards and mimic other RFID tag devices. This is also on my "to do" list but I don't have have an RFID reader to test it at the moment. What I do have is a handful of components in a plastic bag marked "RFID reader" which I used about a year ago to breadboard an RFID reader for an Arduino UNO, I see no reason why they couldn't work with Gamebuino. I don't know what actual gaming applications a Gamebuino-based RFID reader would have but hey, it's all part of the fun
How are you (this feel like a work email!)? This is a great concept... I am very impressed with the demo! I look forward to going over the code too!
As a suggestion, what about using the speaker to communicate? If I understand your concept correctly you are using the changing in the PR to indicate data transmission from one device to the other... can the speaker be read from as well?
**I guess not since it's hooked up to a digital pin.... and I just went over the pin the PR is on is an adc too. So it is converting the change in resistance to a digital representation. Maybe other people can understand this too now!
Well maybe someone can improve the code then? I don't know..
Anyway, Thanks for opening up my mind to the idea of data transmission using the light sensor (NFC). I wouldn't have ever thought about that!!!
Have a good day, Tre
P.s. Haha, I was just about to post this when I wsa told to review your post! Yes, so maybe you can change the speaker pin to a different setting - PD3/INT1/OC2B/PCINT19... I will need to look over these to see if they can be read from in some way... may take a little bit of time for me.
The RFID tag is an awesome additional concept to use the GBO for... I always wanted to listen in on the keys at college and 'see' the data being sent!
That's a great idea, and you actually made it work! Impressive, once again My supplier changed the LED reference without noticing me between the pre-production batch and the 1000pc. batch on the next batches of Gamebuino the bright back-light will be back!
interesting, just wondering but u could use it to write files on the sd card? instead of using a gamebuino to send you could use the flash of a smartphone idea behind that would be to have a small IDE on phone to make games on