If I use LESC security (i.e. Level 4) but use Just Works pairing method instead of Pass Key pairing, will I still be using LESC security? i.e. my concern is that if I use Just Works pairing method with LESC, the Just Works pairing process will reduce the level of security to something less than 4.
Thank you
After consulting the Bluetooth support, the Level is reduced to Level 2.
Related
We're trying to determine whether to use separate GATT characteristics or combine multiple properties into one custom characteristic.
The benefits of combining is fairly clear: one transaction, many properties.
But even with multiple characteristics (one property per), the transaction seems quick enough.
Is this entirely an arbitrary decision? Or are there best practices?
This is highly relevant and depends on the system you're trying to implement. My recommendation is to go for many separate characteristics. The reason is that you will be simplifying the application both on the GATT server side (where all the characteristics are stored) and the GATT client side. For example, if you use multiple characteristics, this means that you have to add extra intelligence to your GATT client side to separate the data in those characteristics. If the data side is variable, then this will be even more complicated. If in the future you have to update this combined characteristic with new features, the task will probably be relatively more complex for both the client and the server side compared to having many characteristics as things will be more categorised and compartmentalised.
Another thing to consider is testing. When you create your GATT server application, you'd want to test it with one or many different GATT client implementations (e.g. iOS device, Linux machine, etc). For that, it will be a lot easier if the remote device is not getting a combined characteristic and trying to make sense of the data.
Finally, please note that as you said, the transaction in Bluetooth is relatively quick and you will not be getting a huge difference when using multiple characteristics vs one. The reason is that by default the characteristic length is 20 and the Bluetooth packet length is 27 (unless you're using a Bluetooth 4.2 feature known as Data Length Extension, which not all phones support). Therefore, even if you use characteristic lengths greater than 20, the Bluetooth stack/baseband will divide the characteristic into chunks and send them over air, therefore not achieving the improved throughput that you aimed for.
I hope this helps.
Hi I am developing an application where an ATSAMB11 device has to send pressure data (from 0 to 6 bar with 5mbar steps) through BLE. I was just wondering if I should implement a custom service and characteristics or I can use the blood pressure service that is already implemented for atsamb11. I am asking because if I use the blood pressure service, it would be much easier as it is furnished with examples and I could write my program over it. Whereas if I have to create my custom service, I don't know where to start and what I need to write. (I precise that it's the first time that I'm working on BLE)
Another option would be to send the data through the custom serial chat service(which is also implemented and have an exemple), but I think that doing so is not the right way to use BLE. Indeed, why would everyone bother about different services and profiles if they could send anything through custom serial chat.
If you can use the standard blood pressure service, do that. Custom services are only used if there is no matching standard profile or the standard profile lacks some functionality one wants.
I have written and simulated a Verilog code in ISE Project Navigator 2013. this is an RTL model that describes the network-on-chip routers, buffers and links.
which device is better for synthesis and implementation?
How can I get the static and dynamic power consumption, a packet transfer delay, area and the other factors that indicates network performance, using ISE Project Navigator?
The question is very open ended so I will try to provide as general an answer as possible.
Now you have said that you have the code for a NOC Router in ISE. This would imply that you or the designer has a rough idea of the frequency at which the internal logic/system has to operate. The maximum clock tree frequency of your target device and would then be one of the key parameters that you need to check. If your design is running at around 150-200 MHz and is appropriately pipelined (small muxes, not more than 2-3 levels of logic between pipelining stages), then almost any of the currently available device families from both Xilinx and Altera should be suitable.
The next important consideration is of external connectivity. Does your design need high-speed serial connectivity with an external device. If that is true, then you would need to select a device that has high-speed SERDES IPs in-built. That would then limit your choice of devices.
Another factor to consider is interface to external SDRAM or RLDRAM. If your design needs to interface with such external devices, then you need to pick a device that has support either through a softcore or a Megafunction (Altera) or a hard IP block.
Finally you need to look at your logic utilization. You want to chose a device that is just big enough to satisfy your requirements, unless your design is part of a bigger project and there are modules that would be designed later and would sit alongside your NOC. You would have to make a rough guess of the number of LEs/LUTs that your design would need and pick a device 50% bigger than that. You can then run a trial synthesis run and check if your estimates are okay. If they are, and your device is less than 50% utilized, you could go in to a smaller device as need be.
There are also a few other considerations such as number of IOs, presence of a PLL/Clock manager that may affect your choice of device
I have this GSM embedded device under linux, where depending on external factors I might chose to put a different sim card into. But in the configuration for the PPP, I have to give an APN, which changes depending on the network du jour. How can I automatize that?
It just downed on me that smartphones don't need explicit APN entry to work when changing the sim card (also, the APN is sometimes different in M2M and actual cell phone, not sure I can use the same trick).
(I know you are curious: it's deployed in the middle of nowhere, and we chose the least worst network at the last minute on the installation site)
You can detect the network operator from the IMSI of the SIM, and have in your device a table mapping operators to APNs.
There are several sites that will provide you an IMSI to operator listing or MCC and MNC to operator listing. The MCC (Mobile Country One) is the first three digits of the IMIS and the MNC (Mobile Network code) the next 2 or 3 digits. Some example links:
https://www.imei.info/carriers/
https://www.mcc-mnc.com
As an aside, if you want to be able to change to adapt to the best available network coverage over time, the way many M2M applications achieve this is to use a 'forgein' SIM which can then roam to the best available signal at a given time. If your data usage requirements are low this can be a good way to avoid being dependent on one operator in an area with poor coverage. There are quite a few companies who specialise in these type of M2M sims, depending on your target location.
I want that my MC52i auto accept an incoming call. If I use AT commands to answer manually (ATA) it works fine, but I'm not able to force the modem auto accepting an incoming call. On other devices it works with ATS0=1 but not on the MC52i. I think it has something to do with the GPRS Mode?
What type of call are you trying to accept, voice or CSD? Setting S0 ought to be enough for this. Try to enable AT+CRC=1 and examine the +CRING: <type> unsolicited result code (see 27.007 for details). Does it fail to auto answer all incoming calls? Try to have it auto answer both voice calls and data calls. Try to call from PSTN, ISDN and mobile phone (both same operator and different operator. Try several different phone models). If it fails to answer all those cases then you probably have to write off auto answer as a possibility. Oh, by the way, also try with several different sim cards (from at least more than one operator) in the modem to rule out problems with the operator/subscription.
I have probably given enough options to tweak so that testing every single combination is not feasible and useful, but pick some variations of all of them and set up at least 20 different test cases.
Although very unlikely, I'll mention the following for completeness and as a background to one of the many reasons why testing with several different operators is important:
There could be a problem if the network does not include call type information in the Bearer Capability in the SETUP message and then the phone does not know how to answer the call. This is very unlikely today, but several years ago some network could behave so. Because of this the phones used to have a "receive next call as" configuration to determine how to behave then. But I assume all newer phones to just ignore this scenario (It was applicable back in the days when Ericsson made mobile phones in their own brand, at least I remember seeing seeing this configuration option in their single menu style phones like T28. I do not remember if it survived the conversion to the icon based menus).