I want to build something with Raspberry Pi Zero and write in Go,
I never tried bluetooth before and my goal is;
Sending a dynamic packet which it will change every second, an iOS app will expand this message and with a button, client will send a message back without a connection.
Is Bluetooth Advertising what I am looking for and do you know any GoLang library for it? Where should I start?
There are quite a lot of parts to your question. If you want to be connection-less then the BLE roles are Broadcaster (beacon) and Observer (scanner). There are a number of "standard" beacon formats out there. They are summarized nicely on this cheat sheet
Of course you can create your own format as these are using either the Service Data or Manufacturing Data in a BLE advertisement.
On Linux (Raspberry Pi) the official Bluetooth stack is BlueZ which documents the API's available at: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc
If you want to be connection-less then each device is going to have to change it's role regularly. This requires a bit of careful thought on how long each is listening and broadcasting as you don't want them always talking at the same time and listening at the same time.
You might find the following article of interest to get you started with BLE and Go Lang:
https://towardsdatascience.com/spelunking-bluetooth-le-with-go-c2cff65a7aca
Related
Recently, I wanted to get my hands dirty with Core Audio, so I started working on a simple desktop app that will apply effects (eg. echo) on the microphone data in real-time and then the processed data can be used on communication apps (eg. Skype, Zoom, etc).
To do that, I figured that I have to create a virtual microphone, to be able to send processed (with the applied effects) data over communication apps. For example, the user will need to select this new microphone (virtual) device as Input Device in a Zoom call so that the other users in the call can hear her with her voiced being processed.
My main concern is that I need to find a way to "route" the voice data captured from the physical microphone (eg. the built-in mic) to the virtual microphone. I've spent some time reading the book "Learning Core Audio" by Adamson and Avila, and in Chapter 8 the author explains how to write an app that a) uses an AUHAL in order to capture data from the system's default input device and b) then sends the data to the system's default output using an AUGraph. So, following this example, I figured that I also need to do create an app that captures the microphone data only when it's running.
So, what I've done so far:
I've created the virtual microphone, for which I followed the NullAudio driver example from Apple.
I've created the app that captures the microphone data.
For both of the above "modules" I'm certain that they work as expected independently, since I've tested them with various ways. The only missing piece now is how to "connect" the physical mic with the virtual mic. I need to connect the output of the physical microphone with the input of the virtual microphone.
So, my questions are:
Is this something trivial that can be achieved using the AUGraph approach, as described in the book? Should I just find the correct way to configure the graph in order to achieve this connection between the two devices?
The only related thread I found is this, where the author states that the routing is done by
sending this audio data to driver via socket connection So other apps that request audio from out virtual mic in fact get this audio from user-space application that listen for mic at the same time (so it should be active)
but I'm not quite sure how to even start implementing something like that.
The whole process I did for capturing data from the microphone seems quite long and I was thinking if there's a more optimal way to do this. The book seems to be from 2012 with some corrections done in 2014. Has Core Audio changed dramatically since then and this process can be achieved more easily with just a few lines of code?
I think you'll get more results by searching for the term "play through" instead of "routing".
The Adamson / Avila book has an ideal play through example that unfortunately for you only works for when both input and output are handled by the same device (e.g. the built in hardware on most mac laptops and iphone/ipad devices).
Note that there is another audio device concept called "playthru" (see kAudioDevicePropertyPlayThru and related properties) which seems to be a form of routing internal to a single device. I wish it were a property that let you set a forwarding device, but alas, no.
Some informal doco on this: https://lists.apple.com/archives/coreaudio-api/2005/Aug/msg00250.html
I've never tried it but you should be able to connect input to output on an AUGraph like this. AUGraph is however deprecated in favour of AVAudioEngine which last time I checked did not handle non default input/output devices well.
I instead manually copy buffers from the input device to the output device via a ring buffer (TPCircularBuffer works well). The devil is in the detail, and much of the work is deciding on what properties you want and their consequences. Some common and conflicting example properties:
minimal lag
minimal dropouts
no time distortion
In my case, if output is lagging too much behind input, I brutally dump everything bar 1 or 2 buffers. There is some dated Apple sample code called CAPlayThrough which elegantly speeds up the output stream. You should definitely check this out.
And if you find a simpler way, please tell me!
Update
I found a simpler way:
create an AVCaptureSession that captures from your mic
add an AVCaptureAudioPreviewOutput that references your virtual device
When routing from microphone to headphones, it sounded like it had a few hundred milliseconds' lag, but if AVCaptureAudioPreviewOutput and your virtual device handle timestamps properly, that lag may not matter.
My team has been struggling with a pretty strange issue while using the WinRT/C++ APIs for Windows to connect to both a MIDI port and receive BLE notifications through a proprietary service on the same device.
The WinRT/C++ library itself is really nice and provides easy and modern C++ interfaces to access the managed Windows runtime classes.
I've pushed a sample repo to Github where we've replicated the issue with a minimal example.
The repo's readme goes over the problem in detail, but I'll post the relevant bits here for completeness.
The sample program is performing roughly these steps:
Check for available MIDI devices using a DeviceWatcher.
Check for available Bluetooth LE devices using another instance of a DeviceWatcher.
Match discovered MIDI and BluetoothLE devices on their ContainerId property (see DeviceInfo for details). This is the method JUCE employs in the native WinRT code for their library, and works as expected.
Open the MIDI port and attach a handler to the MessageReceived event (see the code).
This causes the system to create a connection to the Bluetooth LE device. The program detects this state change, creates a BluetoothLEDevice, we perform GATT service discovery and attach a handler to the ValueChanged event for the characteristic we're interested in notifications from (see the code).
The program then counts how many MIDI messages are received on each port and how many BLE notifications are received from the corresponding device.
The behaviour we notice is that data from the most recently connected device streams just fine, while the throughput for the others is severly limited. We are at quite a standstill regarding this issue, and are not sure where the problem may lie.
We are at quite a standstill here. I'd be more willing to accept it if all the devices would exhibit this behaviour, but that's not the case. Is there any reason that creating both a MidiInPort and an BluetoothLEDevice from the same peripheral should cause this issue?
A BLE radio can only receive or send at any given time. And therefore only communicate with one device at any given time. It uses a scheduler to allocate radio time for every device when you have many devices. That way a second connection can "interrupt" a connection event from another device, decreasing the throughput for that device. See https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multilink_scheduling/central_connection_timing.html
I have been using Windows APIs for NFC communication. I am successful in getting and sending NFC messages from Windows PC, using a local console app. However, I want the communication to be done using a Windows service. Here is what I have:
A C# plugin (DLL), which makes the API calls.
C++/CLI Wrapper that allows unmanaged C++ code, to use the above plugin.
A C++ plugin, that the service will load (this is a requirement, it has to be a plugin)
If I load the C++ plugin into a local console app, and run, it can catch all NFC events (NFC device arrives in proximity, departs from proximity, can read and write to it). But, when I use the same plugin with a service, it is not able to catch those events. I can clearly hear the ping sound that comes when an NFC device comes close to Windows PC, however, none of the event handlers are called (For device arrival, device departure, read or write).
I also tried impersonation thinking that perhaps the context of who calls the method might result in blocking of the events. I could impersonate local user on the service, but the results were the same, no events could be identified.
Is there a reason why I cannot see any NFC events from a service, where as a local console app can get all of them? Again, I am able to hear the ping sound signifying that NFC device is close to Windows PC, but there is no handler getting called for it, suggesting there is blockage of something. Any ideas of what is going on?
Appreciate your time guys!
I'm planing to start some sms based application and currently in feasibility study part. In my application client have to sms their problem to the server and we have to analyse the problem and take reasonable action. Also We have to find the tentative location through which tower they have been connected. I have seen about silent sms feature but not understand. Is any body have experience on how to detect location of sms creator (not in android or iphone). Please help me on determining whether it is possible or not to find the location. If possible then how?
In short this is not possible.
an SMS message weather in PDU mode or text mode does not carry the information to match the source location to the message in any way shape or form.
With reference to the article you linked to in your opening post, I'm sorry to say that there's so much B$$l S$$t in that post that I can smell it from here.
In all the years Iv'e worked with GSM systems, both as a network maintenance engineer and later as a developer writing software to use these systems, not once have I heard of anything such as an 'LMU' or an 'E-OTD' in fact the only acronym that article really got correct was 'BTS' oh and the bit on passing the data over the signalling channel.
As for the silent SMS, well that part actually is true. The special type of SMS they refer to is actually called a Ping-SMS and it exists for exactly the same reason that a regular PING on a TCP/IP network exists, and that's to see if the remote system is alive and responding.
What it's NOT used for is the purpose outlined in the article, and that's for criminal gangs to send it to your phone and find out where you are.
For one, the ONLY people that can correctly send these messages are the telephone operator themselves. That's not to say that it's impossible to send one from a consumer device by directly programming a PDU if you have the necessary equipment and know how. You could for instance pull this stunt off using a normal GSM modem, a batch of AT commands and some serious bit twiddling.
However, since this message would by it's very nature have to go through your operators SMSC and most operators filter out anything from a subscriber connection that's not deemed regular consumer traffic, then there's a high chance this would fail.
You could if you had an account, also send this message using a web sms provider that allowed you to directly construct binary messages, but again they are likely to filter out anything not deemed consumer grade messages.
Finally, if you where to manage to send an SMS to a target device, the target device would not reply with anything anywhere near a chunk of location based info, cell tower, GPS or otherwise. The reason the SMS operators (and ultimately the law enforcement agencies know this info) is because EVERY handset that's attached to the GSM network MUST register itself in the operators MSC (Mobile switching centre), this registration (Known as ratching up) is required by the network so it can track what channels are in use by which device on which towers so that it knows where to send paging and signalling info.
Because of the way the PING SMS works it causes the destination device to re-register itself, usually forcing the MSC to do a location update on the handset which causes a re-registration.
Even then, all you get in the MSC is an identifier of the cell site the device is attached too, so unless you have a database in the organisation of all cell sites along with their exact lat/long co-ordinates, it's really not going to help you all that much.
As for the triangulation aspect, well for that to work you'd need to know at least 2 other transmitters that the device in question can see, and what's more you'd need that device to report that info back to someone inside the network.
Since typically it's only the Ril (Radio interface layer) on the device that actually keeps track of which transmitters it can see, and since the AT commands for many consumer grade GSM modems have the ability to query this information disabled, then it's often not easy to get that info without actually hacking the firmware in the device in question.
How does Google do it? well quite easy, they actually have commercial agreements with network providers that pass the details of registered towers to their back-end infrastructure, in the apps themselves, they have ways of getting the 'BSS List' and sending that list back to Google HQ, where it's cross referenced with the data from the network operator, and the info they have in their own very large transmitter database and finally all this is mashed together with some insane maths to get an approximate location.
Some GSM Modems and some Mobile phone handsets do have the required AT commands enabled to allow you to get this information easy, and if you can then match that information to your own database you can locate the handset your running from, but being able to send a special SMS to another device and get location info back is just a pipe dream nothing more, something like this is only going to work if your target device is already running some custom software that you can control, and if your device is running software that someone else is controlling, then you have bigger problems to worry about.
My son has a MacOS 9 box to which he is sending remote AppleEvents from his Leopard-based MacBook. Is there any way, programmatically, that I can send remote AppleEvents via TCP/IP from my Windows 7 Toshiba?
If it helps, apple events are sent on port 3031 via TCP/UDP.
From the high level, there are four pieces to apple events:
The data aggregation API (data requests are put into an opaque in memory structure). This API as it stands was wordy and painful to use. Thank goodness you have access to languages that have better data aggregation tools
Conversion/serialization - the opaque data structure is turned into something that can be serialized and transported to another process and for same machine events, this may be a null serialization
Transport the data is transported from one process to another. Single machine is probably just enqueuing a copy of the data. Remote machine is transport over a network protocol, which could be TCP/IP (but it works with AppleTalk as well) and may require authentication.
Deserialization/Conversion
You will most likely need to do steps 2, 3, and 4. If you don't care about getting any information back, you can skip 4, since one of the flags in a sent event is "no reply".
There are a relatively small number of types in the AE data model. I would write code on your OS X machine to send each and every type and reverse engineer the packets when they're sent. To speed up the process you might want to use appscript, on the OS X machine which will let you send events from Ruby, Objective C, or Python.
Sniff the packets between the MacBook and the MacOS 9 box using something like tcpdump or Wireshark. This will tell you what an AppleEvent looks like on the wire.
Then replicate those packets using your programming environment of choice on Windows.
I suggest wrapping up the code that you write into a library that you can reuse in other applications.
Good luck - this might be quite tricky!!
if you're talking about growl notification, there are libraries to use that. for example, here is the growl library for ruby