Allowing more than one publish() per second

Firmware
1

How would one go about disabling or changing the one-publish-per-second limit for a Spark Core communicating with a locally run server? I would like to update a value (four of them, actually) about 20 times per second, if possible.

Are there any special considerations I need to know about when disabling or changing the limit? Is it even possible?

Edit: I was surprised to read in another thread that this limit is actually imposed by firmware rather than the server. I’m not sure I understand why; isn’t flooding a more serious concern for a cloud communicating with thousands of devices than the Core?

2

I think it is soft limited in firmware and throttled in the :cloud:.

Will look into this and update you if I managed to do it :slight_smile:

1 Like
3

The limit is actually regulated in both the firmware and the cloud. It's regulated in the firmware to make life as easy as possible for users to write code without having to worry about rate limiting, which turns out to be a fairly dynamic situation to code for.

3 Likes
4

Why not string the accumulated data together and publish all 20 data items as 1 string at once?

5

They’re real-time updates, and are only useful until the next update is published. It won’t be any use to see a backlog of outdated values.

7

I think you’ll need to use post instructions here. Spark.publish won’t cut it at 20hz. Out of curiosity, why would you want to send data at 20hz? Won’t once a second suffice?

1 Like
8

Thanks.

The idea is to have a general and reasonably responsive interface that can be used for a wide variety of applications. If the output represents sensor readings and is being used to navigate a robot, for example, 1Hz won’t cut it unless the robot is moving very slowly. That isn’t one of the planned applications, really, but it’s just an example of something for which 1Hz is insufficient.

9

For these kinds of applications TCP or UDP are perhaps more suited? They’re much more responsive. I don’t think the Server Sent Events were made with these kinds of applications in mind.
Just for the sake of an example though; If you’re using it to control a robot, and it has to respond to your SSEs, you have to take in mind that blinking your eyes takes approximately 200ms. That means that anything quicker than 5 times per second can literally happen in the blink of an eye. Depending on your application, lower speeds may suffice, for which the SSEs can possibly be used.

1 Like
10

Depending on your setup, you could use spark to process most of the data on board so 1hz would suffice.

Keeping things on topic, I agree with @Moors7, TCP/UDP would be more suited. Taking in account that a SSE will go through the cloud etc, it will take quite some time (I’m guessing something in between 100 and 200ms) to actually arrive at your server from your core and vice versa.

5 Likes