Could this be ported to the SparkCore? [image] kayno/arduinolifx arduinolifx - Arduino LIFX bulb This would let us be able to simulate a lifx bulb.

I’m doing a test right now and it might be the way UDP/TCP data is being handled by the CC3000 which is causing issues. Missed out some part of the example code for UDP. adding them in and test now :smiley: At least they are talking now but the code is ignored somehow: -UDP 0 0 0 34 0 0 0 0 0 0 0…

Cool! I tried the arduino and put it in debug mode. It has way more information coming through. The same EEPROM dump is EEPROM dump: 65 114 100 117 105 110 111 32 66 117 108 98 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2…

I have pushed the updated example to github. It’s either my porting skills broke something or the UDP/TCP is having issues. I see that the core managed to receive the right UDP code after some packets being ignored but stopped there. The EEPROM seems fine as anything after the 72 byte is not used…

Indeed its seeing some of the network transmission but stop after a minute and then reset itself. Should there by a some sort of flush command somewhere?

@kennethlimcp could you try printing the result from parsePacket() when receiving the UDP, i think there was an issue with it not respecting datagram boundries… it gives you the size of whole buffer not the size of the datagram And the UDP write sends a datagram for each write and the end packet do…

I think it is possible if you know the size the datagrams should be… or at least know the issue so you cand handle it accordingly. the send thing isn’t an issue there is some overloads for that, not sure who wrote it but it helped me a bunch! //----- UDP + overloading the inappropriate UDP functio…

[image] Hootie81: I think it is possible if you know the size the datagrams should be.. or at least know the issue so you cand handle it accordingly. I think @Hootie81 is exactly right here. I looked at the protocol here and all the UDP packet sizes can be known by reading what packet type y…

How can i add the code by @Hootie81 into the lifx code? It’s beyond me :smiley: I’m seeing a consistent udp,ParsePacket() of 36 @lightx , are you able to use DEBUG and capture the UDP messages sent so that we can compare? I see that the core occasionally manages to read the correct data: ParsePac…

Ive manage to receive a bunch of packet type 2 on the spark. -UDP 24 0 0 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 Received packet type 2 +UDP 29 0 0 1 0 0 0 0 D0 73 D5 0 DE 0 0 0 D0 73 D5 0 DE 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 1 7C 1 0 0 +UDP 29 0 0 1 0 0 0 0 D0 73 D5 0 DE 0…

Porting arduinolifx, a LIFX bulb

General

lightx September 8, 2014, 7:33pm 33

so it looks like porting this code wouldn't be possible because of the problem with UDP (read below)? The LIFX does send/receive UDP from multiple bulbs. Is their a work around for this?

Topic		Replies	Views
Simple UDP program breaks the core Troubleshooting	89	15625	October 9, 2014
UDP issues and workarounds Troubleshooting	29	15036	September 2, 2015
UDP Broadcast problems with simple application Firmware	30	11893	November 19, 2014
LightwaveRF library port for spark Libraries	63	7276	June 3, 2014
Open Lighting Architecture and ArtNet integration Project Share	47	15096	August 1, 2016

Porting arduinolifx, a LIFX bulb

Related topics