The Windows 10 calculator has a "currency" mode with the current exchange rate. From which API does it take the exchange rate?
Related
I have a question regarding BLE. It's my first time trying to use BLE and I am exploring some high level designs for a medical device. The structure would be that the device connects to a stand alone controller-device (wifi disabled) via BLE. The device would be collecting data such as heart rate throughout a 24 hour period. At some point the stand alone controller would be disconnected from the device and connected to an app to transfer the data collected. Can BLE handle the potential data size of this scenario? Is it fast enough to do it in a reasonable amount of time?
Thank you!
Take a look at the specification list provided by the Bluetooth SIG. Two documents describe the handling of heart rate measurements, the most interesting for you would be the Heart Rate Service specification (Download it here: https://www.bluetooth.com/specifications/specs/heart-rate-service-1-0/).
It contains a detailed description on how to transmit heart rate data via BLE. According to the specification you are supposed to use the 16-bit UUID 0x180Dfor the Heart Rate Service. You can find the UUIDs for other services and characteristics in the 16-bit UUID Numbers Document.
I am a researcher working on measuring physiological data such as SpO2, EDA, ECG, and temperature data. We would like to use Galaxy smartwatch 3 as a monitoring device for the research. However, before buying a lot of devices, i need clear and detailed information about the accessibility of SpO2, EDA, ECG, and temperature raw data. If i need to develop a samsung watch app that read and process through custom algorithms raw data coming from these sensors, is it possible?
I just want clear and detailed information before buying a lot of devices.
Figure out that I can use Tizen studio to create a native/web app to retrieve the data.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm new to PCI and would like to use Stripe as my payment gateway. They don't charge monthly fees, and have a good php system to send funds from site to Stripe. Right now I know I can allow customers to put in their card information, use Stripe's framework, and allow the card information disappear. That's fine but my question is:
If I want to store card information in a database for using in Stripe's PHP framework, how do I learn to do it legally?
If you use their Stripe Javascript client to send credit card information to them, what you'll be storing in your database will be a token which represents the client and their credit card, not an actual credit card. If you then ensure that the page where you collect the credit card info is served over HTTPS, you should be PCI compliant.
Using Stripe.js
Being PCI compliant using Stripe
Why would you ever want to do that though?
The beauty of any payment gateway is that you don't have to bother or worry about storing your customers sensitive data, instead you integrate the API with your data layer and consume it as if it was right out of your database.
Stripe provides you with everything you need, their API is very well documented so there really isn't any reason to not be using it in the way I just described.
The simplest way to stay PCI compliant is to never store any card information in any database. Stripe can store the card information for you by using a customer, and attaching card(s) to those customers. You easily access these customers then and charge their card. All you need in your database are the customerId's which keeps you from getting into any PCI issues.
I am trying to understand how Bluetooth BLE works on the iOS programming side. On page https://www.bluetooth.org/Technical/Specifications/adopted.htm, there are two specifications, heart rate profile and heart rate service.
On the introduction of Heart Rate Profile it says
The Heart Rate Profile is used to enable a data collection device to
obtain data from a Heart Rate Sensor that exposes the Heart Rate
Service
On some service like the battery level there is no corresponding profile. What's the difference between the two? One for the sender (service) and one for the receiver (profile)?
The Heart Rate Profile defines an application profile to let a client detect the device as a heart rate sensor.
This profile must include at least the GAP service and the Heart Rate Service for compliance
For battery, the monitoring of a battery level is not an application by itself (or it wouldn't be very useful as an application), but it is relevant to specify a Battery Service for monitoring the battery level within an application.
For example, a heart rate sensor should have a profile compliant with the Heart Rate Profile, so it includes at least the GAP service and the Heart Rate Service. It can also includes (as an option) a Battery Service to enable the monitoring of the battery level of the heart rate sensor
Regards
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Are there any other methods or protocols other than GATT which can be used under BLE (single mode chips) which are better suited to higher-throughput tasks?
From what I understand the answer to my question is no, but I would like some validation and clarification.
I would like to implement services which involve more than simply manipulating (short) characteristics via BLE. Such services might include file transfer, audio streaming, and basically services which are standard in previous versions of bluetooth.
A convenient solution would be to use the File Transfer Profile (over GOEP) or similar for file transfer. For audio, A2DP seems suitable. However, these do not seem to be possible using BLE.
After reading the core spec v4 from bluetooth.org (specifically Vol. 3), it seems like the only applicable protocol which I can use and adapt (via profiles) for such purposes is GATT, which seems very awkward to use.
Also, according to Overview and Evaluation of Bluetooth Low Energy: An Emerging Low-Power Wireless Technology, it seems like the effective throughput is low:
Whereas the physical layer data rate is 1 Mbps, the maximum application layer throughput
is equal to 236.7 kbps.
However (when measuring real-world performance using TI CC254x via GATT):
... In the described conditions, the maximum application layer throughput we have measured is 58.48 kbps. This
low result can be explained by the following two facts: (i) whereas, in theory, up to eleven such
notifications can be transmitted within a connection event of 7.5 ms, only four notifications are
allowed per connection event, as aforementioned; and (ii) we have observed that less than four
notifications are actually transmitted in most connection events during the experiment (however, the
same phenomenon occurs less frequently for connection intervals greater than 7.5 ms). These
observations show that high throughput has not been a primary goal in the design of the BLE
implementation used in the evaluation.
I realize the above text is specific to the implementation on the TI chip, but such limitations could also apply to other implementations above GATT as well.
If you are writing your own profiles, then you can do whatever you want by opening an L2CAP channel and sending data in any format, without implementing GATT. L2CAP would let you get the max throughput, and be suitable for streaming data as opposed to reading characteristics.
Please see what we have been doing for a long time: IPv6 over BTLE, which is still one IETF draft in the 6LoWPAN WG, and the proposal has been approved in Bleutooth SIG. Here is the news in BLuetooth Technical Updates: 19 Feb, 2013.
IPv6 Over Low Energy New Work Proposal Approved
The IPv6 Over LE New Work Proposal (NWP) submitted by Bluetooth SIG
members is approved. This NWP proposes that permitting IPv6 over the
Low Energy transport will enable new use cases (in home and industrial
automation as well as smart metering) not covered by GATT profiles.
The proposed work meets the requirements defined by the Internet
Engineering Task Force (IETF) as well as complements the work done in
the IP for Smart Objects (IPSO) alliance. The Internet Working Group
will develop a Functional Requirements Document (FRD) based on the
approved NWP. If you are an Adopter member and want to participate in
the FRD development process, please contact the Internet Working Group
Chair.
There is stuff coming up, if you're a member of the SIG look up the Tech Specs section of bluetooth.org