The device I'm creating reads a liquid flow meter and logs data to a WebAPI. Ideally it would be able to sleep in a low power state until there was activity on the sensor but I'm not sure how to work that out. Docs say the chip will wake on a falling edge on the RST pin, but I can't have it reset every time input occurs. Is there another way to wake it externally, without pulling reset low? Or I guess I need a relay or SSR that directs sensor input away from RST when the chip wakes (assuming that would happen fast enough to engage the relay before it got reset again?)
Related
When the device is in confirmed mode, it waits for a downlink confirmation (ACK) from the network after each uplink. If the confirmation is not received by the device, it will repeat (up to a maximum of 8 times and increasing the SF of the UL if it was lowered before) the uplink until it receives a confirmation. It may take about 30 seconds to send the 8 repetitions.
If the device does not see a confirmation and needs to send another uplink (e.g. alarm or new periodic measurement), it will send the new uplink and forget the previous one. To operate in confirmed mode, the device must be declared in confirmed mode (or ACK) on the network platform. You can activate it via the IoT configurator in the network parameters
Be aware that this operation consumes much more battery power than a traditional operation, even more, if the network quality is poor.
If the transmitter loses a lot of frames, it would be better to reposition the transmitter (if possible) or the GW (if possible) to improve the transmission rather than activating the ACK which will drain the battery faster than "expected" depending on the network condition.
Is this answer correct or not?
I am sending a signal from an HT12E through an rf transmitter to an rf receiver then an HT12D. This all works fine and the data signal from the HT12D is sent to a CZH-LABS D-1022A(for filling a pool). The pulse triggers the relay on the CHZ so that works ok.
What I want to do is take the same pulse/signal from the HT12D and send it through a 3vdc regulator (it is currently at 5vdc) and then through an EC2-3TNU latching relay.
The relay would then turn on power to an ESP12E, which would connect to the wifi and send a message to ThingSpeak that the original signal was received and the pool filling relay triggered.
The problem is that even though the signal from the HT12D reads 3vdc and it lights up an LED light when the signal is received, it doesn't trigger the latching relay.
I am attaching a schematic to show the wiring of my project.
To summarize:
The 5vdc (converted to 3vdc) signal from the HT12D will light up an LED but won't trigger a 3vdc latching relay EC2-3TNU.
I thought I may be the size of the smoothing capacitor after the center tap rectifier, but if I connect the ESP12E up to 3vdc and the activate the signal the LED still lights up but the latching relay won't engage.
I am flummoxed! Can anyone think of why the latching relay isn't activated by the 3vdc signal? Could it be I need a larger capacitor? The latching relay works because if I tap it with a 3vdc lead it triggers. This has nothing to do with code so I'm not providing any. Although once the ESP12E is activated, connects to the wifi and uploads to ThingSpeak, the ESP is coded to turn on an output pin to activate the latching relays reset pin turning off the ESP until the next signal input.
Any suggestions to solve this problem or a work around would be greatly appreciated.
I can't create tags and one for HT12D or HT12E would really be helpful.
I got this figured out. Just added a transistor, diode, and resistor.
I am using the Socket iOS SDK with the 7Xi scanner. The scanner is fast enough to register duplicate scans in quick succession if a user holds a barcode in front of the scanner when in stand mode. To handle this, I am simply removing my scan delegate when the first scan arrives, and not setting it again until I am ready for the next scan.
Of course, the scanner itself continues scanning. Is there some way to silence the beep while I am handling the scan, so that my users don't think the scan was correctly received when the app does not. It must be fast enough that I can reliably re-enable it within a second or so.
Background
The scanner has three confirmation modes (device, sdk and app) which determines who is responsible for acknowledging a barcode was scanned. The default is device, which will acknowledge any successful scan (i.e. the barcode type is supported and the device successfully decoded the barcode).
Solutions
Option 1
Currently, you remove the scan delegate, which doesn't prevent the scanner from scanning the next barcode; It only prevents your application from receiving the event notification. You provide ScanApiHelper with a timer routine that calls doReceive to check for new events and if it finds one it calls your delegate.
You could add a flag to your timer so that it will only call doReceive when you are ready to handle the next event.
There are two limitations to this approach. There will be a delay between the device acknowledgement and feedback from the application, if important feedback is provided, when a scan is held in the queue. Second, a queue is only suitable for handling a brief burst of activity, but your application will require downtime to catch back up.
Option 2
Caveat: I'm not sure if this works in presentation mode
Switch the confirmation mode to app and have your application acknowledge the barcode after it is done processing. This has the benefit of essentially locking out the scanner (it won't beep, flash or vibrate for any scan) unless your application has received and handled the barcode.
The downside here is there is a small lag between the barcode being read and the scanner acknowledging it, when using app confirmation mode. Adding an additional delay while processing the data may not be the best user experience.
We are working in a groupon-like app where alerts are displayed to the user when he/she enters in the range of an offer.
The client insists on having alerts even when the app is in the background.
Due to the architecture of the system, the app gets the location of the client at intervals and checks with the server if there is any new alert. If so, the app does some processing in the local database and displays a notification.
APN cannot be used since changes in the server are out of reach for this project.
My question is whether Apple would accept it in AppleStore as I have read different opinions about it and Apple discourages its use as in this extract from iOS Developer Library
http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html
At wake-up time, your app is put into the background and given a small amount of time to process the location data. Because your app is in the background, it should do minimal work and avoid any tasks (such as querying the network) that might prevent it from returning before the allocated time expires. If it does not, your app may be terminated
Thanks
How often does your app get location from the user? According to Apple's Background Execution and Multitasking, if you are getting the location updates on a regular schedule (I think it's less than 10 minutes), your app can still process in the background if you add location to UIBackgroundModes in your info.plist. With those CLLocation coordinates, you can then process your web service requests.
I personally have not done something like this, so I can't tell you for sure if Apple will reject your app or not. However, if everything is within the guideline and requirements set by Apple, I don't see why they would reject your app.
EDIT:
From the Apple doc:
An app that provides continuous location updates to the user (even
when in the background) can enable background location services by
including the UIBackgroundModes key (with the location value) in its
Info.plist file. The inclusion of this value in the UIBackgroundModes
key does not preclude the system from suspending the app, but it does
tell the system that it should wake up the app whenever there is new
location data to deliver. Thus, this key effectively lets the app run
in the background to process location updates whenever they occur.
I guess even if the app is suspended, it will wake up whenever there is a new location data to deliver.
I think you should reconsider your approach for this application. It sounds like you have decided to build a set of features which are not necessarily well informed by, or a good fit for, the characteristics of the devices the app will run on.
You write that "the app gets the location every n minutes" but that's not how iOS location services work. Querying location services for the current location occasionally is a good approach when your app is running in the foreground but that's not an option once it is suspended or terminated. Instead you need to subscribe to location events, at some level of accuracy, and your app will be notified when the device's location changes. There are no guarantees about the schedule on which you receive these events and it varies depending on the accuracy you request and the speed at which the device is moving.
Additionally, obtaining a location is an expensive operation and can quickly drain the device's battery. Burning through a user's available battery power in an hour or two is a very good way to get your app uninstalled quickly. Where possible you should be using the significant location change service to get low accuracy location updates with minimal power consumption. If you need more precision then consider using boundary crossing events for a defined region or at least reduce the accuracy your have requested as much as possible.
With all that out of the way you still need to work within the limited time your app has to run once started by a location update. That's probably not long enough to make a round trip to the server. If a network connection is already active and the device happens to have low latency you will probably get a response some of the time but I would expect to see the app terminated by the OS frequently. When that happens I don't know that you will continue to receive location updates which might otherwise re-launch the app.
Instead of downloading a list of alerts and displaying them locally a better solution might be to attempt to send your current location to the server via UDP when you see a significant location change. That way you can fire off a network request without waiting for a response. Only some of those requests will still succeed but at least your app won't be terminated. You can then process the locations you receive on the server and send push notifications when appropriate.
I realize that you don't seem to be able to make server side changes. In that case the best you might be able to do is pre-fetch alerts for the nearby region when the app runs (and if you ever manage to complete a round-trip while in the background). That way you could compare location updates to that list and not need to fire off a network request on every location update. Unfortunately it sounds like you might be backed into a corner here with no reliable solution available under your current constraints.
I made a simple game which connects to other peers using GKSession from GameKit. It was easy to set up but I discovered some problems:
Latency varies a lot. Sometimes message arrives instantly on other devices. Sometimes latency is > 1 second for sending data to other peers. Data is only a string with 10 chars.
My game depends on precise clock synchronisation. The game has music playing and it sounds odd when it doesn't start playing the same time on all connected devices.
I couldn't find anything in the documentation about how to snychroize timing. The problem is that the "master" pier which starts the game immediately begins playing the music and then all other piers receive the message a little bit later and thus start playing after delay.
Then I tried to delay playing the game music after sending the start message to all piers, but sometimes latency is lower or higher and I just can't get a good reliable sync.
Is there a open source framework which makes peer to peer and clock sync more reliable and easier to use on iOS?
Unfortunately, you're in for a world of hurt here. It is very difficult to do precise clock synchronization over a network interface. You would need your devices to sync to within 20ms here.
I would recommend doing the following: send a bunch of ping packets at 50ms intervals, make the client respond immediately. Take the average of this to give you average round trip time (RTT) and then halve that to estimate the one-way latency. Then send your 'start clock' message and spin in a loop until you've waited for your one-way latency and begin playing the music on your end. The client should play its music immediately upon receiving 'start clock'.
There is a more robust long-term sync solution outlined here: http://en.wikipedia.org/wiki/Precision_Time_Protocol