I've developed an iOS app that can read RSSI values from the surrounding Estimote Beacons. These RSSI values are fluctuating and to get a smooth value I need to use a filter. I am trying to use [Kalman filter] which needs some past RSSI values. Now, I am able to get the current RSSI values but cannot store them in database for filtration purpose. How can I store these RSSI values in database? I am using Objective-C for coding.
Thank you.
At the line before you store the current RSSI value, take that value and store it in a similar variable called previousValue or something similar. Then you can do what you wish with it. As it's an NSNumber type, just invoke previousValue.intValue or similar to be able to store the type you need (or just store the NSNumber itself).
If you need more values just add each previousValue to an array variable. You shouldn't need that many previous values though for a Kalman filter, surely.
If you do need to store the data, CoreData or using SQLite directly are two possibilities. Or store the data in a UIDocument. If your question is really asking how to do these things, I would re-state your question. Otherwise there are countless resources for those techniques...
Related
I want to offer the user the choice of imperial or metric measurement of weight in my app to increase audience suitability. I have designed the following below to allow me to determine which setting the user wishes to use.
However, im unsure how I would go about applying the metric selection to the whole rest of the app? Would it be a case of setting the app reach into each object the user has created in coredata and all text labels relating to a weight measurement and alter their weight property by multiplication or division each time the user changes weight system?
Appreciate any insight into how I may achieve this as I didnt want to go too far in the wrong direction!
func convertAppMetric() {
if self.userSelectedWeightSystem == "Metric" {
print("THE USER SET THE APP TO METRIC, CONVERTING FIGURES...")
//some code
} else if self.userSelectedWeightSystem == "Imperial" {
print("THE USER SET THE APP TO IMPERIAL, CONVERTING FIGURES...")
//some other code
}
}
This is going to be one of those answers that SO hates, but you want to go read up on NSMeasurement.
NSMeasurement holds both a value and a Unit, the later of which is the original measurement type. You store all your data in the format that was originally provided - if the user puts in pounds, store a NSMeasurement with 182 pounds. If they put in kg, make one with 90 kg. You can even put in your own Units, like stone.
From then on, always present the data using an NSMeasurementFormatter. You can pass in the output type, which in your case is the global setting you mentioned in your question. This means that no matter what unit they provided, it always comes out properly converted to the one you want, and changing it instantly changes it everywhere.
Its easy to make your own converters for weird units. I made one for decimal inches and feet/inches, so 13.5 inches turns into 1' 1.5".
I want to transfer some records with the following structure between two Windows PC computer using COM/DCOM. I prefer to transfer an array, say 100 members of TARec, at a time, not each record individually. Currently I am doing this using IStrings. I am looking to improve it using the raw records, to save the time to encode/decode the strings at both ends. Please share your experience.
type
TARec = record
A : TDateTime;
B : WORD;
C : Boolean;
D : Double;
end;
All the record's field type are OLE compatible. Many thanks in advance.
As Rudy suggests in the comments, if your data contains simple value types then a variant byte array can be a very efficient approach and quite simple to implement.
Since you have stated that your data already resides in an array, the basic approach would be:
Create a byte array of the required size to hold all your record data (use VarArrayCreate with type varByte)
Lock the array to obtain a pointer that is safe to use to reference the array contents in memory (VarArrayLock will lock and return a pointer to the array data)
Use CopyMemory to directly copy the data from your array of records to the byte array memory.
Unlock the variant array (VarArrayUnlock) and pass it through your COM/DCOM interface
On the other ('receiving') side you simply reverse the process:
Declare an array of records of the required size
Lock the variant byte array to obtain a pointer to the memory holding the bytes
Copy the byte array data into your record array
Unlock the byte array
This exact approach is something I have used very successfully in a very demanding COM/DCOM scenario (w.r.t efficiency/performance) in the past.
Things to be careful of:
If your data ever changes to include more complex types such as strings or dynamic arrays then additional work will be required to correctly transport these through a byte array.
If your data structure ever changes then the code on both sides of the interface will need to be updated accordingly. One way to protect against this is to incorporate some mechanism for the data to be identified as valid or not by the receiver. This could include a "version number" for example and/or a value (in a 'header' as part of the byte array, in addition to the array data, or passed as a separate parameter entirely - precise details don't really matter). If the receiver finds a version number or size that it is not expecting then it can report this gracefully rather than naively processing the data incorrectly and (most likely) crashing or throwing exceptions as a result.
Alignment/packing issues. Even with the same declaration for the record type, if code is compiled with different alignment settings then the size required for each record in memory could change (which is why a "version number" for the data structure format might not be reliable on its own). One way to avoid this would be to declare the record as packed, though this comes at the cost of a slight reduction in efficiency (and still relies on both sides of the interface agreeing that the data structure is packed).
There are just things to bear in mind however, not prescriptive. Just how complex/robust your implementation needs to be will be determined by your specific case.
I am reading characteristic properties from a BLE device from my iPhone.
However, some of the properties I am seeing (like 0xA, 0x22) are not in the enumerated list that Apple provides. Are these properties a combination of 2 or more enumerated values? Or are these custom properties from the manufacturer? Need guidance on this.
As you can read in the documentation:
Values representing the possible properties of a characteristic. Since
characteristic properties can be combined, a characteristic may have
multiple property values set.
In other words, a characteristic may have more than one property. That makes sense as you can, for example, have a characteristic which can be read (CBCharacteristicPropertyRead) and written to (CBCharacteristicPropertyWrite).
In this case the value of CBCharacteristic's properties would be the bitwise OR of CBCharacteristicPropertyRead and CBCharacteristicPropertyWrite, which is 0xA.
I'm trying to use butterworth filter. The input data comes from an "index array" module (the data is acquired through DAQ and I want to process the voltage signal which is in an array of waveforms). when I use this filter in a case structure, it doesn't work. yet, when I use the filters in the "waveform conditioning" section, there is no problem. what exactly is the difference between these two types of filters?
a little add on to my problem: the second picture is from when i tried to reassemble the initial combination, and the error happened
You are comparing offline filtering to online filtering.
In LabVIEW, the PtbyPt-VIs are intended to be used in an online setting, that is - iteratively.
For each new sample that is obtained, it would be input directly into the VI. The VI stores the states of the previous iterations to perform the filtering.
The "normal" filter VIs are intended for offline analysis and expects an array containing the full data of the signal.
The following whitepaper explains Point-by-Point-VIs. Note that this paper is quite old, so it should explain the concepts - but might be otherwise outdated.
http://www.ni.com/pdf/manuals/370152b.pdf
If VoltageBuf is an array of consecutive values of the same signal (the one that you want to filter) you only need to connect VoltageBuf directly to the filter.
My purpose is to record the change on RSSI a single beacon.
Firstly i monitor the region of a static UUID, then select the beacon of interest.
So i ended up with one single CLBeacon object. The problem is that, the RSSI value does not change on this object (not surprisingly), i have to find the interest beacon from "..didRangeBeacons:(NSArray *)beacons" each time i need the new RSSI value.
I already tried to use always the pointed object, but i hope there is a convention for that.
I hope my statement is clear, is there a known solution for that ?