I’m working on a project with a mobile app that will request data from the agent. I would like the agent only to respond to the request when it has appropriate data from the device, but am having trouble getting that set up.
First question: Is the best way to do this to constantly poll the agent with the mobile app at some short interval and check the response for data? This does work just fine, but seems like excessive traffic.
I did program the agent and imp similarly to one of the Rocky examples that responds to a request only after getting data from the device, using the context.id, but even though my timeout is set to 30 seconds, the Agent responds with a timeout response after 10 seconds.
I’m developing the app in Unity so that it can be built for many platforms, but some of those will be mobile and this the app will need to initiate every request.
The project is an internet connected PCP air rifle target trap, and the app keeps track of shooters, hits and misses for each match.
Interesting. So maybe when a shooter steps up they scan-in with an rfid tag they wear on a lanyard? Some piezo detectors register hits or misses by where they are located? Depending on how many targets there are I imagine a micro controller for each one. The scanning of rfid tag would be the trigger that begins a timer, records shots, and logs them out when finished? Sensors connected to imps … or one imp is the “master “ that communicates with the app? You could also use a website as your API (cloud of data).
Piezo sensors can detect shots hitting a surface. Imp analog input pin. RFID tag reader to UART, SPI, or i2c
I have a basic functioning game/app written. Shooters log in, and then start a match. The app keeps track of hits, misses and who is shooting.
On the hardware side, I am using an LIS3DH accelerometer to detect “misses” on the target trap backstop, which is a 2’ square sheet of steel right now. I’ll probably use momentary switches on the actual targets, but accelerometers would work just fine too as long as I can differentiate hits.
PCP air rifles are rather powerful, and even the entry level gun I am using gets 800fps with a .22 caliber pellet. It actually puts dimples in the plain sheet steel that I am using, so I am testing harder steel right now.
The Imp006 breakout looks very nicely suited to this project, especially since it fits a mountable aftermarket case. I have loads of 002 hardware laying around, but the 2G service would be great if the latency is low.
I’ll likely post this entire project on GitHub if anyone is interested.
Looks like you’re way ahead of us on this one. If this is outdoor, you could build some sort of solar charger for the hardware (LiPo batteries). Assuming also you don’t have WiFi available, which is why you are going to the SIM card option (imp 006)? The imp006 also has the li-ion cell input for battery. I think it’s a cool idea … bring it anywhere since it’s cell phone (not WiFi). You could buy one imp006 and test the latency with just a simple momentary switch. See if it would be fast enough to transmit every shot. It would only transmit shots after a person logs-in. It’s the shot hitting that would send the data. Once they log-out, it resets. Data could also be saved in files on a website using PHP/SQL database.
I’m always curious about the SIM devices that use cell phone towers … such as particle.io
If they now require LTE and are obsoleting even G3 service?
WiFi works just fine in my backyard, but a mobile data connection would be great for taking it off site or out to an actual range. Bluetooth on the 006 might be a decent option as well, if the range works. I’m shooting at about 30 yards right now. The 006 breakout has an accelerometer on it, which is perfect since I can mount the case right on the back of my trap.
Solar is definitely something to look into, since I really could have the imp sleep in between hit registers. The 002 hardware that I’m testing with right now has a LiPo charger and the imp runs for quite a few hours at full power on the little 380mAh battery that I have attached. I’m curious as to how well the “Fuel Gauge” function of the charger on the breakout works.
Still trying to figure out if I can get long polling to work, since I hate banging on the agent every second or so, but it probably is more reliable than long polling in the long run.
When a pellet strikes, the imp (device) tells the agent to send a hit or miss to your app. Your app then updates the count in its own memory. Nothing happens until the next pellet strikes. If at any time you ‘wish’ to get a count update, you could ask the agent for a count, since the device is also keeping track. But you don’t need to poll the agent unless you don’t think the app is keeping the correct count. The data could also go to a website for archival storage. Your app would know how much time has passed between pellet strikes. If the user logs out or no strikes are received in 60 seconds, you assume they are done and put the imp to sleep until the next person logs in.
Because a website is also containing data, you or anyone with an admin login could use a laptop or tablet to get an instant snapshot of all shooters or shots taken, regardless of the app.
Of course you should make a whole write up on this when finalized. I’m sure this would interest others … even for other sports. Or maybe a beer pong championship… or cornhole competitions.
On a mobile device, there is no way for the agent to reach out to the mobile app, it isn’t an endpoint like a webserver. That means the app has to reach out to the agent, which is fine, but the agent might not have data. In my current program, whenever the device records a hit or a miss, it sends that to the agent, that just stores it in a global. The next time the app reaches out, it gets the shot data, and then the agent clears it. I have the app polling the agent every second while the match is running. Right now, I am shooting with a bolt action gun, so there is quite a bit of time between shots. If I wanted were shooting with a semi-auto, I might need to up the pace a bit to makes sure I didn’t miss anything, or maybe send more than one shot per query.
When the agent is ready it will publish a message to a known topic (can include wildcards) and then the mobile app will be subscribing to the same topic. That way there is no polling needed any more, it gets events as they sent and messages can be sent in both directions very simply.
Thanks James, I appreciate the suggestions. I do want to keep this project as simple as possible, and unfortunately, adding in another service often times also adds latency, cost and possible points of failure. I’m sure there has to be a way to do what I want using impOS, I just need to find it. If it turns out that interval polling is the best way, well, it does work just fine, but seems less than elegant.
