Timeout Error on Photon, causing it to restart every 30 seconds

Troubleshooting
1

Hi,
I am getting a timeout error, error 408, every 30 seconds, causing my Photon to restart and therefore mess-up my data transmission. I realized this when I was sending the data to a Google doc but happens also when simply publishing an event to the Particle Cloud (dashboard). I tried a few things out from online but still have no clue what is causing the issue, if you can help me out that would very much be appreciated!
Thanks!

Below is my code:

int sensor1 = A1;
int sensorV = 0;
char sensorStr[12];


void setup() {
    pinMode(sensor1, INPUT);
    Particle.variable("sensorV", sensorStr);

}

void loop() {
    sensorV = analogRead(sensor1);
    sprintf(sensorStr, "%d", sensorV);
    delay(1000);
    Particle.publish("Sensor", sensorStr, 60);
}
2

I wonder if you are not overflowing sensorStr.
did you try making this buffer bigger...

char sensorStr[12];

or using the safer

snprintf(sensorStr, sizeof(sensorStr), "%d", sensorV);

?

3

tried both and still doesn’t work.

code updates:
int sensor1 = A1;
int sensorV = 0;
char sensorStr[64];

void setup() {
pinMode(sensor1, INPUT);
Particle.variable(“sensorV”, sensorStr);

}

void loop() {
sensorV = analogRead(sensor1);
snprintf(sensorStr, sizeof(sensorStr), “%d”, sensorV);
delay(1000);
Particle.publish(“Sensor”, sensorStr, 60);
}

4

I just changed the delay times, when its less than 1000ms it doesn’t transmit anything, and when its more than 1000ms it works well (yay?!). But for my application I need to record and then transmit at a rate of 1000Hz or 1000 times per second. Any alternatives to reducing the delay but getting the program to work? Or ways to send chucks of data packets?

5

There’s a publish limit of 1p/s, so 1000Hz isn’t viable using that. That also explains why it’s giving you issues when you’re going lower than the 1000 delay.
What exactly are you planning on doing that requires that resolution if you don’t mind me asking?

6

I guess this is related to this issue
https://github.com/spark/firmware/issues/1023

And less than 1000ms is not wirking due to the rate limit if 1 per sec (as mentioned in the docs)

1 Like
7

I need to record data from an analog force sensor on a hockey skate wirelessly. As the force information goes vary quickly when skating so I need to sample at 1000 times per second.
I.e. Sample data @ 1000 times per second from sensor (or atleast 480 times per second), transmit the data to the Cloud (can be sent 5 seconds after sampling) (i.e. to a Google doc) to then be saved, and all this initially triggered by a button press.

Any suggestions on how to buffer the data for 2 seconds then transmitting it all in a packet, wirelessly to the cloud? And a function for starting/ending data transmission by a button press on a computer?

8

For that kind of speed I’d go with TCPClient pushing the data to a local server rather than Particle.publish().

9

Ok. And would the local server be the Google doc? And would the server code go in the Particle or Google script code? First time for me dealing with a client to server connection.

10

Once you got the data off the Photon onto a less limited server (e.g. a RasPi or full fledged PC) you can do with it what you want. Either process the data there and then or, if you need, push it on to Google Docs (without bandwidht or timing restrictions)

11

@benlandry5, can you give a few more details on the data capture:

  • It sounds like you need sampling at 1000Hz for 2 seconds for a total of 2000 samples, correct?
  • How many bytes (or what data types) does each sample consist of?
  • Once sampling is complete, you have 5 seconds to send the sample data?
  • Is sampling locked out until all data is received and a button is pressed?

A workflow (steps) of the sampling logic would be great. The big challenge with using Particle.publish() is the data size limitation and the max publish rate. @ScruffR if right about using TCP instead. However, depending on your sampling requirements and timing, it may still be possible to use multiple Particle.publish().

1 Like
12

Ok. My issue is that the closest computer would be 20m away from the Particle device, however the user would have a cellphone on them (and my wifi is hotspotted from my phone to the particle). Can the Photon transmit as far as 30m? Would it work to transmit data from Photon to a cellphone and then Cloud (easily). And transmitting it to a computer, wouldn’t somewhere I’d need server code, i.e. Photon has TCPClient, but where would TCP server code be located? [and I don’t need to use Particle.publish(), it’s just for prototyping; I just need a way to store information].

13

20~30m should be possible if there is little interference/obstruction. With a uFL antenna you could increase that a bit more.
Also you don’t need the computer in reach, only the access point/router to which both can connect, a WiFi repeater/extender would also be useful.
And if you use a cell phone as hotspot you’d need a way to reach your server via a public IP and you’re good to go too.

14

Well I don’t really care for the Particle.publish(), I’m just using it for the prototyping phase but I need Particle.variable to store the data to then be accessed by Google docs.

I have an analog force sensor in which I need to sample at 1000Hz for 1 minute. Preferably the data is sent in real-time, if not, with some delay, if not after 1 minute of recording. The data is transmitted by the Particle to the Cloud or transmit to a computer if the transmission can reach 30m away. The wifi source is produced by my cellphone by hotspotting.

The main workflow is: sensor --> Particle --> Cloud or unknown storage device --> to be saved for later uses in MATLAB.

For your questions:
-60000 samples in 1 minute
-Each sample of data type, int [think an int is 2 byte but not sure]
-Best case its done in real-time, otherwize delayed a few seconds, otherwize once sampling is finished it transmits all the data. This project is for research purposes, so as long as I get the data reliably and sampled quickly, I’m happy.
-Sampling is not locked out, having a button press would be a good tool to initialize with the other sensors. But I’ve opted out now of using the button because it’s not essential.