Just got started on BLE Beacons and wrote up a small program to locate beacons and list some services etc. The following is the result that I can print in the console.log
BLE service:
Service handle: 43
uuid: 00001800-0000-1000-8000-00805f9b34fb
characteristic: 00002a00-0000-1000-8000-00805f9b34fb
characteristic: 00002a01-0000-1000-8000-00805f9b34fb
characteristic: 00002a02-0000-1000-8000-00805f9b34fb
characteristic: 00002a03-0000-1000-8000-00805f9b34fb
characteristic: 00002a04-0000-1000-8000-00805f9b34fb
BLE service:
Service handle: 44
uuid: 00001801-0000-1000-8000-00805f9b34fb
characteristic: 00002a05-0000-1000-8000-00805f9b34fb
descriptor: 00002902-0000-1000-8000-00805f9b34fb
BLE service:
Service handle: 45
uuid: 0000180a-0000-1000-8000-00805f9b34fb
characteristic: 00002a25-0000-1000-8000-00805f9b34fb
characteristic: 00002a26-0000-1000-8000-00805f9b34fb
characteristic: 00002a29-0000-1000-8000-00805f9b34fb
BLE service:
Service handle: 46
uuid: 0000c050-0000-1000-8000-00805f9b34fb
characteristic: 0000c051-0000-1000-8000-00805f9b34fb
characteristic: 0000c052-0000-1000-8000-00805f9b34fb
characteristic: 0000c053-0000-1000-8000-00805f9b34fb
characteristic: 0000c054-0000-1000-8000-00805f9b34fb
characteristic: 0000c055-0000-1000-8000-00805f9b34fb
characteristic: 0000c056-0000-1000-8000-00805f9b34fb
characteristic: 0000c057-0000-1000-8000-00805f9b34fb
characteristic: 0000c058-0000-1000-8000-00805f9b34fb
characteristic: 0000c059-0000-1000-8000-00805f9b34fb
characteristic: 0000c05a-0000-1000-8000-00805f9b34fb
descriptor: 00002902-0000-1000-8000-00805f9b34fb
characteristic: 0000c05b-0000-1000-8000-00805f9b34fb
characteristic: 0000c05c-0000-1000-8000-00805f9b34fb
characteristic: 0000c05d-0000-1000-8000-00805f9b34fb
BLE service:
Service handle: 47
uuid: 0000c090-0000-1000-8000-00805f9b34fb
characteristic: 0000c091-0000-1000-8000-00805f9b34fb
descriptor: 00002902-0000-1000-8000-00805f9b34fb
characteristic: 0000c092-0000-1000-8000-00805f9b34fb
characteristic: 0000c093-0000-1000-8000-00805f9b34fb
characteristic: 0000c094-0000-1000-8000-00805f9b34fb
characteristic: 0000c095-0000-1000-8000-00805f9b34fb
BLE service:
Service handle: 48
uuid: f000ffc0-0451-4000-b000-000000000000
characteristic: f000ffc1-0451-4000-b000-000000000000
descriptor: 00002902-0000-1000-8000-00805f9b34fb
descriptor: 00002901-0000-1000-8000-00805f9b34fb
characteristic: f000ffc2-0451-4000-b000-000000000000
descriptor: 00002902-0000-1000-8000-00805f9b34fb
descriptor: 00002901-0000-1000-8000-00805f9b34fb
These beacons are basically transmitting 2 values - temperature and voltage of the beacon itself. While I am up reading some more notes, I was wondering if someone could point to which of these UUIDs/characteristic that I need to focus on, to be able to get the temperature and voltage readings? As I do more reading and research, I would really appreciate if any experienced developer could give some pointers? Basically I need to enable the notification on the temperature and voltage service. I can figure out from the BLE libraries how to enable the notification but how do I locate / point to the correct service/characteristic/descriptor etc? Thanks once again
I got an Arduino board with ble to scan and capture some data from the beacons
[ADV 22587] Packet received from 50:65:83:10:E6:3A
PAYLOAD 30 bytes
02-01-06-1A-FF-6A-00-0F-75-E9-D5-AD-15-DF-FB-48-01-52-4E-8A-4B-B9-3D-0F-00-1E-3B-9E-FF-2C
RSSI -68 dBm
ADV TYPE Connectable undirected
MAN SPEC DATA 6A-00-0F-75-E9-D5-AD-15-DF-FB-48-01-52-4E-8A-4B-B9-3D-0F-00-1E-3B-9E-FF-2C
[SR 22618] Packet received from 50:65:83:10:E6:3A
PAYLOAD 22 bytes
12-09-69-57-45-45-43-41-52-45-20-54-65-6D-70-20-50-61-6C-02-0A-00
RSSI -68 dBm
ADV TYPE Connectable undirected
COMPLETE NAME Temp mini Sensor
TX PWR LEVEL 0
Any pointers on how I should continue from here? Trying to just get a hang of it ... just that elusive lead ... and I think I'd have understanding of what's going on :)
Bluetooth Gatt services simply allow you to read and write characteristics on the Bluetooth peripheral. Typically peripherals are designed so that writing certain patterns to certain characteristics controls what the peripheral will do.
To take an example from your question, writing some pattern to some characteristics might control whether the connected Bluetooth central is notified of changes in temperature and/or voltage, based on crossing a threshold or at a regular interval.
The key thing to understand is that the way you configure the Bluetooth peripheral all depends its system design. It is not standard. You really need documentation from the manufacturer to tell you how to do this. Without such documentation, you are basically reverse-engineering the Bluetooth peripheral.
It may be helpful to get a better answer to your question to identify the manufacturer and model of this beacon device. If you don't see any documentation on the manufacturer's website, the perhaps the manufacturer will answer this question directly, or somebody else who has reverse-engineered the device will do so.
Related
im tried to use Janus to call in videoroom. the problem is the remote video success to display, but only publisher can not show in janus videoroom, after check log i see :
RTCIceConnectionState didChange state 1
RTCIceConnectionState didChange state 4
/** Represents the ice connection state of the peer connection. */
typedef NS_ENUM(NSInteger, RTCIceConnectionState) {
RTCIceConnectionStateNew,
RTCIceConnectionStateChecking,
RTCIceConnectionStateConnected,
RTCIceConnectionStateCompleted,
RTCIceConnectionStateFailed,
RTCIceConnectionStateDisconnected,
RTCIceConnectionStateClosed,
RTCIceConnectionStateCount,
};
After read admin api, i see the document say about my error:
Let’s see an example of a “broken” PeerConnection instead:
"components": [
{
"id": 0,
"state": "disconnected",
"local-candidates": [
"1 1 udp 2013266431 172.17.0.3 46008 typ host\r\n",
"2 1 udp 2013266431 143.225.229.138 60710 typ host\r\n",
"3 1 udp 2013266431 2002:8fe1:1cc3:b:5c48:51ff:fee9:11ef 58925 typ host\r\n",
"4 1 udp 2013266431 fec0::b:5c48:51ff:fee9:11ef 52486 typ host\r\n"
],
"dtls": {},
"in_stats": {},
"out_stats": {}
}
]
In this example, ICE is “disconnected”, which means the ICE connectivity checks never started at all. As a result, the DTLS and data stats sections are obviously empty, as Janus never got to the point of involving them. What is the cause of the problem here? Looking at the data Janus provides, one thing immediately pops to the eye: there are just local candidates (the ones Janus gathered for itself), but no remote candidates at all: this means that the client failed to send them to Janus for some reason (e.g., your client is not sending trickle candidates) and so Janus can’t do anything to establish a media connection.
Can anyone explain me the problem, note that subscriber work normal!, i mean i can get remote video and display in my phone, but my phone can publish video to janus
When open rtc error log, i see too much line about:
(stunport.cc:279): Jingle:Port[0x1248a2e00:audio:1:0:local:Net[en2:169.254.0.x/16:Wifi]]: UDP send of 100 bytes failed with error 65
RTC log updated below
https://pastebin.com/EE7Jhz75
solved, coz of proxy server is not auto mapping from ios, google chomre + safari auto mapping.
I have a rather complex server-client setup where the server essentially acts as a relay for certain packets between two unique clients. Don't worry, I made a diagram, but here is the summary.
The packet starts with the server, goes to ClientS, then ClientS sends a packet back as response, which the server then relays to ClientP. Then upon receiving packet, ClientP send a different packet back to the server, which it then finally relays to ClientS (supposedly).
Diagram A
Problem (check edit after)
The annoying part is that this only works up until step #4. For some reason when the server does the final net.Write to the UDP connection, it is somehow picked up but server's own net.Read from #2 instead of the net.Read from ClientS. Another diagram illustrating the problem.
Diagram B
Code
In terms of the code from the server. I'm doing two net.DialUDP's, each to dial a connection to the two clients. After that connection is "established", there is a net.Read waiting in a goroutine on each connection.
At the moment the code is a bit all over the place and I don't want to just dump it all here. However here are the functions for each of each step in the diagrams and how I'm dialing the UDP connections. (obviously it won't compile, but maybe enough to spot something?)
clientSConn, err := net.DialUDP(udpNetwork, localClientSAddress, remoteClientSAddress)
clientSConn.Write(b []byte) (int, error) { … // <------- #1
clientSConn.Read(b []byte) (int, error) { … // <------- #2
clientSConn.Write(b []byte) (int, error) { … // <------- #5 this byte[] is read by #2 ¯\_(ツ)_/¯
clientPConn, err := net.DialUDP(udpNetwork, localClientPAddress, remoteClientPAddress)
clientPConn.Write(b []byte) (int, error) { … // <------- #3
clientPConn.Read(b []byte) (int, error) { … // <------- #4
Assumptions/Tests
When I dial from local to remote address and do a write, the data can only go out TO the remote address given to dial. Same with read, data can only come FROM remote address of dialed connection.
I started this project using net.Listen and it gave me much stranger results. net.Dial eventually solved most of my initial issues. Maybe I'm still confuse what the difference is?
I tried net.ReadFrom and net.ReadFromUDP, but both gave me same result as net.Read.
I tried net.WriteTo and net.WriteToUDP, but neither sent any data over to the clients.
EDIT (SOLVED!)
Turns out the issues was rather obvious and embarrassing. #5's Write isn't looping into Read, it was just doing #1 and #2 again since the connection for #1 and #5 is the same.
I'm using the ST I-Cube End-node sample code (in C) embedded on the B-L072Z-LRWAN1 discovery kit board and transmitting a LoRaWAN packet to my End-node device.
I'm seeing that the packet has been received by the end device because it prints:
"PACKET RECEIVED ON PORT 1"
But I don't know how or where the received packet is stored.
How can I print and access the packet data/payload that I have transmitted to my node?
Appreciate the help!
A function with the signature void LORA_RxData(lora_AppData_t *AppData) has been declared and defined wherein the lora_AppData_t contains the downlink LoRaWAN payload.
The available member variables are:
message buffer: AppData->Buff
Size of the message buffer: AppData->BuffSize
Port of the received message: AppData->Port
This all can be found in the files lora.h and lora.c. These files contain ST's implemenentation of the LoRaMac-node
The function is defined with __weak so you can define your own LORA_RxData to process the data on your own terms. If you don't redefine it it will use the default.
My gateway uses the Raspi and RFM95 configuration and operates at 915 MHz. I am using the single channel packet forwarder code by tfelkamp (https://github.com/tftelkamp/single_chan_pkt_fwd).
My gateway only the detects the first message it received and ignores the all messages afterwards. It is still connected to the TTN server but does not receive any more messages.
Can anyone explain what might be the cause of this? Might it because the RFM95 sleeping or the code no longer forwarding the message from the transceiver.
Thanks
I experienced a similar issue. Please note your sender is using different channels, but starts with channel(0). This is the first successful message you receive. Your single channel receiver is just able to receive channel(0). There is a work around for this issue for your sender explained here
This sounds like your transmitter sends the messages using frequency-hopping, while your receiver does not handle it correctly (or the other way around).
Definition of frequency-hopping found in chapter 4.1.1.8 of Semtech's SX1272 datasheet:
Frequency hopping spread spectrum (FHSS) is typically employed when
the duration of a single packet could exceed regulatory requirements
relating to the maximum permissible channel dwell time. This is most
notably the case in US operation where the 902 to 928 MHz ISM band
which makes provision for frequency hopping operation. [...]
If you're using the LMIC-Arduino library for your node then yes, by default it is transmitting in a range and the single_chan_pkt_fwd gateway is only receiving on the frequency you specify in the global_conf.json or the .cpp source (depending on your chosen library).
With the assumption that you're using the arduino-lmic library, make the changes/additions mentioned in the this TTN forum post linked by Rainer which is the same I ran into.
Also... you'll find this further down the thread: in src > lmic > lmic.c edit the following:
void LMIC_disableChannel (u1_t channel) {
if( channel < 72+MAX_XCHANNELS )
//LMIC.channelMap[channel>>4] &= ~(1<<(channel&0xF)); // comment this one
LMIC.channelMap[channel/16] &= ~(1<<(channel&0xF)); // add this one
}
Then pick a frequency on channel 0 and set that for both node and packet forwarder. Here's a table snip from this page. I went with 902300000 and it's working fine.
"freq": 902300000,
"spread_factor": 7,
I am using SimplePing sample from Apple to ping to a host which successfully received a response from the framework delegate
func simplePing(pinger: SimplePing!, didReceivePingResponsePacket packet: NSData!)
Which I am struggled to find the way to to decode the packet data (e.g. get the host name, ip)
I know that it's something about CFNetwork but I just can't find the right way to read the data, hope someone can help.
If anyone stumble upon this topic in pesent, like me.
Host name or ip address can be found in pinger property. If that is what you looking for.
Example:
func simplePing(_ pinger: SimplePing, didReceivePingResponsePacket packet: Data, sequenceNumber: UInt16) {
print("Host: \(pinger.hostName)")
}
The sample provides a method called icmpInPacket: that returns a broken-out struct. Use that. :-)