Putting back in box (update: took back out of box...)


#10

Thanks for the update. If it weren’t for you, I’d never have seen that the banner at the top had changed. I really do appreciate what you do here.

The Argon updated easily, and then I had a hard time getting the Xenon to take the update, it was flashing cyan with an occasional red blink and even after cold rebooting that didn’t change. But it’s done, and so far so good after 2 hours of uptime. I’m going to leave it running the test overnight, but I doubt there will be problems.


#11

FWIW, I had the same issue with one of my Xenons. It tried doing the OTA update but got into some weird loop where it was flashing red/blue on and off. I resolved it by doing a factory reset and setting it up again, it’s working fine now.


#12

Ok, @ScruffR, thanks for the update!

I installed rc.26, and things went a lot smoother. I have been able to update 1 Argon and 3 Xenons, and have the soft pulsing teal light, the indicator that they are all connected and happy. I have been able to signal them from the console.

Also, have been able to turn them off, individually, and together, and turn them back on, individually, and together, and with only a couple of hiccups, they all came back online.

Hopefully this means I’ll be able to get some sensors hooked up to them and start communicating with them.

Thanks for your help!


#13

In an effort to improve on this end, what do you think Particle could do differently? How, when, where, and what kind of information would you like to receive from Particle?


#14

I’ve been waiting for the new firmware all week (good job by the way!). My only comment would be that it wasn’t obvious that the new firmware had been released. I know it’s posted in the Problems and Fixes post, but it wasn’t advertised all that well. Maybe a sticky at the top of the Mesh subforum would have done the trick?


#15

Yup, I also expected the announcment to be made in this thread

But maybe it’s because the mesh branch and the Gen1/2 branch of the firmware haven’t been merged yet, they keep it separate for now.


#16

Hey folks – released this late last night so will help to cross-pollenate in threads throughout the day.

Right now the updates thread is pinned to the top of Particle Mesh category and we’re updating the global header whenever there are new updates to the Known issues and fixes thread.

Open to suggestions about how we can better spread the word – we have the team in support mode today to help customers with the transition to rc.26 and understand where there are still issues that we can work to resolve.


#17

Hopefully the need to turn off IPv6 networking is resolved in the latest rc.26 update. Please let us know you see an improvement with Xenon reconnect behavior with this release.


#18

I’m thinking they’re worse now.


#19

Would you be able to share how it’s worse? At what steps are you still experiencing issues?


#20

So I worked my way through the green blinking light deal the other night and they’re all breathing cyan and all, I flash the new firmware, or at least I think I do and they appear to be in the web ide, but then they’re breathing cyan, but I can’t ping or signal them, they’re just flaky. So back to the drawing board, I’m trying to do the CLI to flash the argon first and get it hopefully where it needs to be. But this is all just weird. Gotta use the CLI for this and the WEB IDE for that and the console to look at this…I’m looking for the Little Orphan Annie secret decoder ring to better understand what needs to be done. This is way too much jiggling the handle to get this stuff to work. I learned yesterday that there is the firmware and then bootloader stuff, and system 1,2,3 stuff and now this ncp firmware… I’m sure a lot of it all is me, but…Ahh just frustrated.


#21

Hey @ksprayberry – I totally understand and agree that your experience sounds like a frustrating one. Our intention is for the development experience to be much smoother than what you described.

If you’re willing to share your Device IDs and source code with our developer support team, we can take some of the “troubleshooting” burden off of you to get your devices into a good state. You can do so by shooting a note to our team at http://support.particle.io

Otherwise, @mstanley and @ParticleD are here to help as well.


#22

I think I just got the Argon flashed with both the firmware and I got the ncp on it. So maybe I’m on a roll. I’m going to use CLI to make sure the Xenons are flashed right now. If I run into issues, I’ll definitely take you up on the offer. Remember OCD is great as long as it’s pointed in a useful direction.
Thanks
Kelly


#23

Glad to hear it! If you have tips that might benefit others, let us know what “worked” and we can document it if it’s not done so properly already.


#24

So now I have both the Xenons and the Argon flashed over and breathing cyan again and I was able to ping all of them. I think the next thing I need to do is get a better understanding of how to flash my program using the CLI instead of the Web IDE. If I’m undestanding it all correctly, if I have my ino file and then all the libraries… ccp, .h files, etc. in a directory, any directory, then I can go to that in the command prompt mode and compile it and flash it. that might get me around all this file or directory not found business. On to that next.
thanks!


#25

You know what would be helpful? I’d really like to see a video or two of the argons or xenons with someone flashing a fairly complicated program with multiple libraries. Either by way of the IDE or using CLI. I don’t know what I’m doing wrong, but I can’t get anything to upload on the web ide that has a library (DHT) and I’ve been trying tonight to upload a DHT11 program (using CLI) and it just stalls out and says something to the effect of …target/workspace.elf failed. On the web ide it always says Missing file or directory.


#26

Well, rc26 appears to be another bust.

I’ve left my mesh running since my last post here last night. It seemed to working properly. After 20 hours without touching anything, I started power cycling the xenons while leaving the argon alone. They consistently reconnected flawlessly and took anywhere from 3-6 seconds to get from receiving power to breathing cyan, which seams to be working properly.

The Argon was basically running code printing sensor data from the xenons to an OLED and also printing its uptime. I made it to 23 hours, 45 minutes, 11 seconds and the Argon appears to have hard crashed. The LED is breathing cyan, the OLED is not updating, and D7 which would indicate incoming data from the xenon is stuck on.

The console ping for both devices shows them as unreachable.

The Xenon LED is flashing green and the D7 LED is blinking to indicate it is still running through the loop sending the sensor data.

Edit: After 30 minutes like that, I pressed the Argon’s reset button. After about 25 seconds the Xenon went back to breathing cyan and the system appears to be working again.


#27

My 2 cents… I love it when it works, but v26 isn’t the step forward I was hoping for. I’ve currently got an argon gateway, and 2 xenon slaves. As I mentioned in another post, my gateway (an Argon) rarely makes it more than 8 hours before needing a power cycle. Without the power cycle, I can’t signal or flash either xenon. The argon is running a trivial program (the LED/light sensor with published variables/function example). Pretty sure I could signal the argon before rebooting it, but need another 8 hours to verify that). The xenons were still succesfully communicating between themselves with the mesh.publish/subscribe even though I couldn’t contact them, so pretty sure the problem lies with the gateway.


#28

Thanks for the report. This sounds like a deadlock either in the system code or the user application. Do you use SYSTEM_THREAD(ENABLED) ? Since you are saying that the device is not reachable from the cloud, it sounds most likely that you are not, so adding that should help figure out where the deadlock comes from: system code or the application code. You can also PM me the application and I’ll take a look at anything suspicious.


#30

UPDATE: I’ve uploaded new binaries that enable logging from an ISR.

I would appreciate if you could flash the following debug system firmware. They will automatically log on Serial1 @ 115200, you should not instantiate Serial1LogHandler in the user application. Unfortunately we cannot reliably log from an ISR to Serial. If you don’t have an UART-USB adapter, you can use another device running a simple app and connecting its RX to TX of the device being debugged.

SYSTEM_MODE(MANUAL);
void setup(void) {
    Serial1.begin(115200);
    Serial.begin();
    while (true) {
        while (Serial1.available() > 0 && Serial.availableForWrite() > 0) {
            Serial.write(Serial1.read());
        }
    }
}