Gateway Shield with Electron


#1

There had been an issue with TCPClient in the Electron that fully stopped this integration from working, but the new 0.5.0-rc.2 release from Particle now allows them to work great together! If you would like to see how to upgrade your Electron to this version, please see here: https://github.com/spark/firmware/releases/tag/v0.5.0-rc.2

One note, the Electron uses a new version of protocol to talk to the spark cloud based on UDP instead of TCP. Bluz, on the other hand, still uses the same TCP protocol that the Photon and Core use. Therefore, it sends a heartbeat to the cloud every 15 seconds and this will absolutely eat up a lot of your data plan on the Electron if you leave this running round the clock.

The long term solution is to switch bluz to UDP, but that may be far off. There is one good side, and that is that bluz already uses a hidden feature on the TCP side that allows these heartbeats to not happen, but the cloud still reports it as online. Normally with a Core/Photon, if it doesn’t get the heartbeat after X iterations, the cloud says it is offline. But bluz can turn that off, and the only way the cloud thinks it is offline is if the TCP socket actually closes.

So, a feature we need to get in place quickly is the ability to turn off the heartbeats in bluz. We will try and get this done quickly, and it will be optional. The other option, and more immediate solution, could be to throttle the traffic at the gateway for now. The Electron knows when a device connects, and knows how big the heartbeat packet is. So some simple filtering in the Electron could stop the traffic from going through, but still allow important traffic (function calls, publishes, etc.). This is a hack, for sure, but it could work in the immediate term if someone needs to get this working quickly and doesn’t want to pay a bunch for data.


[SOLVED] Issues with New Gateway Shields
#2

#3

One change, the 0.5.0 release has gone GA. You can find he fully released firmware here: https://github.com/spark/firmware/releases/tag/v0.5.0


#4

updated my electron (G350) to 0.5.0 using the CLI tool, then flashed the gateway application OTA via the Particle IDE…

Does not work.

I tried the hot plug trick which works with the spark core, but no luck - electron is breathing cyan, but there is no flashing LED on the GW shield to signify advertising connectivity to my BluzDK.


#5

What is the behavior? Does the LED L2 on the GW shield blink when the Electron starts breathing cyan?

Also, can you capture the serial output? So with the Electron plugged into your computer, open your favorite serial program and open the port at 38400 baud rate. You should see a bunch of output from the Electron, can you post that here?


#6

ok… with the electron powered via USB port, and breathing cyan (after about 4 reboots), i hot plugged it into the unpowered GW shield, which now has a flashing LED L2.
My BluzDK is not picking it up though, and is flashing green still.

This is the Debug on the Electron:

31961:DEBUG: STARTING!
66354:DEBUG: In SPI Receive
66354:DEBUG: Handshake complete
66356:DEBUG: Receiving SPI data of size 6
66356:DEBUG: Reading chunk of size 6
66358:DEBUG: Processing message of size 3 with clientID 0 and service ID 1
66359:DEBUG: Disconnecting Client0
66359:DEBUG: Read length = 1
66369:DEBUG: In SPI Receive
66369:DEBUG: Handshake complete
66371:DEBUG: Receiving SPI data of size 6
66371:DEBUG: Reading chunk of size 6
66373:DEBUG: Processing message of size 3 with clientID 1 and service ID 1
66374:DEBUG: Disconnecting Client1
66374:DEBUG: Read length = 1
66385:DEBUG: In SPI Receive
66385:DEBUG: Handshake complete
66387:DEBUG: Receiving SPI data of size 6
66387:DEBUG: Reading chunk of size 6
66389:DEBUG: Processing message of size 3 with clientID 2 and service ID 1
66390:DEBUG: Disconnecting Client2
66390:DEBUG: Read length = 1
66401:DEBUG: In SPI Receive
66401:DEBUG: Handshake complete
66403:DEBUG: Receiving SPI data of size 6
66403:DEBUG: Reading chunk of size 6
66405:DEBUG: Processing message of size 3 with clientID 3 and service ID 1
66406:DEBUG: Disconnecting Client3
66406:DEBUG: Read length = 1
68431:DEBUG: In SPI Receive
68431:DEBUG: Handshake complete
68433:DEBUG: Receiving SPI data of size 28
68433:DEBUG: Reading chunk of size 28
68436:DEBUG: Processing message of size 25 with clientID 3 and service ID 1
68436:DEBUG: Connecting Client3

Spark Core works ok still, and BluzDK connects.


#7

I am pretty sure that the Electron doesn’t have 0.5.0. That is the exact problem we saw before the fix was rolled out via Particle.

Do you have the CLI installed? With the Electron, can you do a ‘particle identify’? It should tell you the firmware version.


#8

If I try to use ‘sudo particle identify’ with the electron blinking blue (listening mode) then I get the Device ID, IMEI and ICCID, but then an error about being unable to open /dev/ttyACM0 and unable to determine firmware version.

If I open the tty with screen, and send the ‘v’ command I get back the firmware version - 0.5.0

The Particle web IDE also reckons I have version 0.5.0 on the device.


#9

Sorry to keep pressing on this, but did you update to 0.5.0 r1? That, I think, may show the cloud that you are on 0.5.0 but the fix didn’t come until r2.

Did you update over USB? The only way I can create this error is if I have the old firmware on my Electron.

Also, is this a 2G or 3G device?


#10

It’s a 2G G350
I followed these instructions: https://github.com/spark/firmware/releases/tag/v0.5.0

And I did it using the CLI, over USB,


#11

I just tried a 2G Electron (had done most of my previous testing with a 3G one) and I still see it working ok.

One thing, when did you grab the Particle code? You may want to take the latest from the repo: https://github.com/bluzDK/particle-gateway-shield-code/blob/master/particle-gateway-code/particle-gateway-code.cpp

It has changed and at one point didn’t work with the Electron. That was a while ago, but wouldn’t hurt to get the latest and greatest.

The only other thing I can recommend is trying to update the Electron to 0.5.0 again. The issue still looks like the old TCP bug.