OSMv2.1 Pinout Diagram

#1
OSMv21_pinout.jpg
Please login to download files. Registration is free. If you are logged in already, you do not have permissions to download this file. Please contact us for support.

Re: OSMv2.1 Pinout Diagram

#3
fmosm wrote:What is "green adc in" this is unique to the 2.1?


Yeah look at #15 on the 328 whereas on OSM2 on #15 it showed as N/C for no connection. Honestly i'm not sure what it's for, but def something new for the OSM2.1

Re: OSMv2.1 Pinout Diagram

#4
Myles wrote:
fmosm wrote:What is "green adc in" this is unique to the 2.1?


Yeah look at #15 on the 328 whereas on OSM2 on #15 it showed as N/C for no connection. Honestly i'm not sure what it's for, but def something new for the OSM2.1


I believe it is for chip to chip communications in much the same way the Aether chips are able to send settings wirelessly using just the LEDs.

Re: OSMv2.1 Pinout Diagram

#5
I did a simple test to verify what "Green ADC" is by reading the A1 analog sensor value when shining a flashing LED pattern on the LED.

Here is the sensor reading when shown a certain type of LED strobe pattern:
ss+(2016-10-14+at+12.55.46).png


And the sensor reading when shown a different pattern:
ss+(2016-10-14+at+12.55.17).png


As you can see there is clearly a way to transmit data using just the OSMs which opens an exciting door of functionality not unlike the Aether chips.

I even tested the sensor reading when pointed at a phone screen flashing a strobe pattern:
ss+(2016-10-14+at+01.02.43).png


Which means a phone app could potentially program all lights at once by simply playing a generated flashing pattern. Settings could be traded with simple gifs!
Please login to download files. Registration is free. If you are logged in already, you do not have permissions to download this file. Please contact us for support.

Re: OSMv2.1 Pinout Diagram

#7
z3r0skillz wrote:Dude his is freaking amazeballs! can't wait to see what can be done. Possibly RF? If so it could totally be done using a phone with RF blaster.

I did a test with a Galaxy S5 IR blaster and unfortunately the LED does not respond well to it. I think the best bet is something on the spectrum of visible light. So a protocol needs to be developed where modes can be encoded, transmitted, and decoded all done chip side.

This would be a function similar to what the Aethers are capable of and if a phone or desktop app is made, these developments technically could trickle down to owners of Aether chips as well, allowing customization on a computer before transfer to chips.

I also hear the new "bluetooth" Spectras also use tech based on what the Aether uses for final mode transfer. Of course this is all spitballing on my part, I don't have the requisite coding experience to implement anything soon but I have demonstrated it is within the realm of possibility.

Re: OSMv2.1 Pinout Diagram

#9
notchars wrote:I did a simple test to verify what "Green ADC" is by reading the A1 analog sensor value when shining a flashing LED pattern on the LED.

Here is the sensor reading when shown a certain type of LED strobe pattern:
ss+(2016-10-14+at+12.55.46).png

And the sensor reading when shown a different pattern:
ss+(2016-10-14+at+12.55.17).png

As you can see there is clearly a way to transmit data using just the OSMs which opens an exciting door of functionality not unlike the Aether chips.

I even tested the sensor reading when pointed at a phone screen flashing a strobe pattern:
ss+(2016-10-14+at+01.02.43).png

Which means a phone app could potentially program all lights at once by simply playing a generated flashing pattern. Settings could be traded with simple gifs!


Good work, this is really cool, I would like to see this on my computer as well so I can tinker. Can you give me a couple search terms to lead me in the right direction? Is this through the serial monitor or a custom sketch that you used?

Re: OSMv2.1 Pinout Diagram

#10
jonathan43551 wrote:Good work, this is really cool, I would like to see this on my computer as well so I can tinker. Can you give me a couple search terms to lead me in the right direction? Is this through the serial monitor or a custom sketch that you used?


Right, so at the moment I just used a custom sketch to dump the A1 value so it can be read while hooked up to the serial monitor.

Code: Select all

void setup() {
  Serial.begin(9600);
}

void loop() {
  int sensorValue = analogRead(A1);
  Serial.println(sensorValue);
  delay(1);
}


At some point I would like for a modified NEO firmware to use edge detection on the incoming sensor data, store it, then play it back which would demonstrate the ability to correctly transmit and receive data via the LEDs. After that, steps can be taken to implement some sort of protocol that would allow mode sharing. I'm interested in seeing what you come up with.

Who is online

Users browsing this forum: No registered users and 5 guests

cron