I want to use a SensorTag 2 so that it is sitting there broadcasting it's data (and, critically connectable over bluetooth) from when it's turned on to when\if I ever turn it off. Out of the box, the tag is set to only advertise over Bluetooth for a few mins which means that when the connection eventually fails or when the device connected to the tag boots etc etc you can't connect again without physically visiting the tag and resetting it.
I see there is firmware that the myWeatherCenter people have created that lets the tag work as a weather station by basically setting it to advertise indefinitely... frustratingly though their firmware is only the sensortag version 1 :-(
I've researched on and off for months and months now and nothing coming back.. suggesting either nobody else wants this, there is a really simple solution everyone one else knows about or ...? I can't even see anyone else asking this question really... which is worrying.
Does anyone have a firmware file that sets this setting for the sensortag 2 or know how to modify the firmware to set this setting?
It is definitely possible to change the SensorTag 2/CC2650 platform so that its behavior suits your use case. I - for example - currently use a custom firmware doing pre-processing of sensor readings on the SensorTag and sending data directly in the advertisement message indefinitely (of course you have to tweak intervals and payload to get a decent battery life).
I assume you have CCS and the sources (SensorTagApp and SensorTagStack) at hand?
I recommend flashing the current SensorTagStack first, if not done yet (though I'm not yet on 2.2 myself).
In the SensorTagApp project under Application you find SensorTag.c. In there you should change:
#define DEFAULT_DISCOVERABLE_MODE GAP_ADTYPE_FLAGS_LIMITED
to
#define DEFAULT_DISCOVERABLE_MODE GAP_ADTYPE_FLAGS_GENERAL
This is the usual advise and might already do the trick.
In my firmware I also changed (in SensorTag.c, in the SensorTag_init function):
uint16_t advertOffTime = 0;
to
uint16_t advertOffTime = 1;
Please try these changes and get back to me. If that wasn't enough I will do a more thorough comparison of the stock firmware and my custom firmware. I also recommend the more specific ti Bluetooth low energy forum.
You could find the workflow for a complete solution and the firmware for continuous advertising which I created recently, at Sensortag CC2650STK Custom Firmware Modification&Download Workflow (Continuous Advertising) using Code Composer Studio, Debugger DevPack and Flash Programmer 2 software
Related
I'm checking this source for scanning BT LE advertisement messages with BlueZ:
https://github.com/edrosten/libblepp/blob/master/src/lescan.cc
Mainly it does this (pseudo):
hci_fd=hci_open_dev(dev)
hci_le_set_scan_parameters(hci_fd, static_cast<int>(scan_type), interval, window,
own_type, filter_policy, 10000);
struct hci_filter nf;
hci_filter_clear(&nf);
hci_filter_set_ptype(HCI_EVENT_PKT, &nf);
hci_filter_set_event(EVT_LE_META_EVENT, &nf);
setsockopt(hci_fd, SOL_HCI, HCI_FILTER, &nf, sizeof(nf)
hci_le_set_scan_enable(hci_fd, 0x01, filter_dup, 10000);
In case I set hardware filter (by setting filter_dup to 1, I'm not getting my desired messages immediately. They come only at a low-frequency (1/min). That's fine, as the hardware filtering disables the duplicates, and I guess there is a timeout after which it let's them in again. (This seems to be exactly 1 minute in my case).
Turning off the filtering causes a huge traffic arriving in, from which I would only need all messages from a specific mac-addressed device. Can I somehow add a whitelist to the scanning command?
Then it can give me all the packets from my desired device, and leave out all the rest.
How can I do this with BlueZ over HCI?
I think your best option is to filter the messages within your code. I don't know of anything in the API to have it filter messages on the hardware level like you describe.
There is a "whitelist" function in BLE, but that's related to specifying a list of addresses that you want to connect to and then you let the hardware automatically connect to just those addresses. (sounds like you actually want just the ad packets and not actually connect, though)
EDIT:
I think I was wrong... Look at the filter_policy to hci_le_set_scan_parameters. If it's 0x1 then I think it filters based on the whitelist. I don't know how to set the whitelist, though.
I found it very useful looking at the source code for hcitool and gatttool when trying to understand the bluez library C calls. https://github.com/bluez/bluez/blob/master/tools/hcitool.c has reference to an "acceptlist" which seems to be what you want.
I'm working on some home automation programs and one of the things I want to be able to do is detect when my 4th generation Apple TV has woken from sleep. This will generally only ever happen when someone pressed a button on its Siri remote to wake it up.
I have a PC (connected to the same TV as the Apple TV) that has a Pulse-Eight USB-CEC adapter, so naturally the first thing I tried was using CEC to determine when the Apple TV is awake. Unfortunately it's not reliable, since monitoring the Apple TV's power status to see when it wakes up produces false positives. (I should note that I do not have "Control TVs and Receivers" enabled on the Apple TV, and can't turn it on for the particular project I'm working on because I need the Apple TV to not change the TV's input.)
I'm trying to think of some other way to do this. I'm open to any possibilities, including things like:
Making use of private APIs on the Apple TV
Running an 'always on' program in the background of the Apple TV that sends a signal when the Apple TV wakes up, if that's even possible. (I suspect that it isn't.)
Monitoring the bluetooth communication between the Siri Remote and the Apple TV, if that's possible
Somehow filtering HDMI-CEC commands so that I can turn on 'Control TVs and Receivers', allow the Apple TV's CEC commands for turning on and off the TV, and exclude commands for changing the TV's input.
Any other method, no matter how hacky or ridiculous, as long as it works!
Does anyone have any suggestions? I'm running out of things to try!
I tried to post below on apple discussion / support communities but was told i don't have the right to post this content. Maybe someone in this group can succeed in doing it:
Apple TV 4 CEC integration is great when it works, but it doesn't work all the time and not with all the various equipment out there, you can do a search across forums and you will see lots of unhappy users. I would like to use a raspberry PI to detect when my AppleTV goes to sleep and wakes up and programmatically turn my tv on or off using its RS232C or custom CEC commands.
I used a bonjour services explorer and compared every single result between sleep and on states and there are no differences whatsoever. I would have expected Apple to welcome such automation projects and make this information readily available with a variable such as status: sleep or status: on.
Is there a way I could tell the two states apart via the network connection?
If not, could one build a TvOS app which runs on the background and makes this information available to clients somehow?
I finally found a method that seems to work consistently. This method is incredibly hacky and not at all the sort of way I'd prefer to do this, but it's the only one I've found so far that works consistently.
I have taken an old USB webcam and affixed it to the front of my Apple TV so that its lens is directly in front of the Apply TV's front facing light. Whenever the Apple TV is asleep, I simply check for the light turning on by taking images from the camera and analyzing their average luminosity. Since the lens is right next to the light, when it turns on it'll create a huge blown out white circle in the image that's incredibly easy to detect.
As long as the Apple TV is asleep, the light turning on seems to indicate 100% of the time that it has woken up. I have yet to find a single incident of either a false positive or false negative.
Since pressing buttons on the Siri remote causes this light to blink, this also means that I can detect buttons being pressed by looking for changes in the light while the Apple TV is awake. It's not 100% accurate, since some button presses are faster than the frame rate of my crappy old USB webcam, but it works well enough.
I would vastly prefer to find a better method of doing this, like making a request over the LAN to the Apple TV where the response clearly indicates it being awake or asleep, but so far it doesn't look like that's possible.
Here I am, six and a half years later, and I've finally found a better way to get the power state of my Apple TV.
I can simply use pyatv, which has a function named power_state that returns the Apple TV's current power state.
Does anyone know how to reset an Advanced Card Systems NFC reader type ACR1255U-J1? I've sent an escape command to it and it got stuck. When I switch the button at the top I get a purple light for LED1 and orange light for LED2 followed by red light for LED1 and no light for LED2. Any help will be appriciated.
I can see the device through Mac Terminal when it is connected through USB but it is no longer visible when bluetooth is on.
Once the ACS1255U-J1 shows the behavior you described it's basically bricked. It happens because of a stack overflow problem (no pun intended) in the readers' firmware and ACS is currently working to correct it. I've seen it happen repeatedly with very long Escape Commands like the Rewrite Master Key Command Request (36 bytes long) as well as some shorter ones. Depending on the severity of the overflow, you may be able to resurrect the reader by reflashing it with fresh firmware. You can download all the stuff you need from our site here:
http://flomio.com/ACR1255U-J1-FlashTool/
You'll need a Win7 machine to work the tool and even then it'll take a few tries to get the reader in DFU mode. If you run into issues, post support questions on our forums and we'll be happy to help.
That said your device corruption may be beyond repair. This can happen if you've wiped out the boot sector of the flash. You'll know this if the reader fails to enter DFU mode. I've been able to resurrect a few readers but found them lacking some key setting like the serial number field being gone (all zeros). But more just don't enter DFU. We're authorized distributors of ACS products so if you want to RMA your device through us let me know and we can work something out.
UPDATE: Flomio now has the ability to repair bricked ACR1255U-J1 units. You can ping us on our forums for details.
I want to do some testing by sending layer 2 packages with wrong FCS/CRCs.
I've searched scapy/mz/nemesis, but it seems none of them could play with it.
Is it possible to do this on a regular linux NIC? Or if the FCS/CRC is automatically appended by hardware that we cannot do anything with it?
I have some specific machine to detect all incoming packets before dropping them, so I want to test if it does work like that.
No you cannot, as far as my experience with most NICs go. You can, however, disable automatic checksum calculation at the rx side, manipulate it at the buffer desccriptor layer and give it to stack.
Googled it for you. These guys say intresting things. Take a look.
http://dev.inversepath.com/download/802.3/whitepaper.txt
Yes you can. I've found another discussion on this here: How do you send an Ethernet frame with a corrupt FCS?
There is a link going to a working example (http://markmail.org/thread/eoquixklsjgvvaom). I've tried that and it's working (on igb and e1000 Eth cards).
I'm using a Virtex 5 FPGA and want to have a few +5/0 I/O pins to communicate with a microcontroller. The only peripherials I've used on the board so far are pushbuttons and switches and no one I've asked seems to know the simplest way to do this I/O. I've looked around the board specification but haven't found any simple way of doing it. I would appreciate any advice you might have.
This is not an easy thing to do. If you don't have the schematic of the board, then you need to get volt meter with some fine pitch probes and reverse engineer the board.
It is pretty easy if you have 2 boards, with one board it can be really hard since the BGA signals may not be connected to a via and therefore not available on the bottom of the board, and even if they are, then you don't know exactly which pin they are connected to. But with some luck, you can find them since the VIA can only be connected to 4 possible pins surrounding it!
The first thing you need to do is to identify your chip, find the BGA print of the IC from Xilin'x web site.
If your board has some buttons already, then if you are lucky, those signals may be routed to the pins of the FPGA that are available on the bottom of your board. Here are the things you need to do:
Make sure you have good ESD protection to perform these test
Put your voltmeter into 'buzzer' mode
Check the pins of your connector and find out how it is connected, see if there is a pull-up and/or pull-down resistors on the board
when you find the 'active' pin of your connector, start connecting the other probe to the VIAs one by one
When you hear a buzz, make a note of the position (guess or measure the distance between the side of t he IC and the location of the via)
Identify the 4 possible pins that the signal can be connected to
Write a code to get all those 4 signals and connect them to ChipScope
In Chip Scope, capture all 4 signals and see which one is the one with the right connection!
alternative, you can create a design with inputs only, capture all the inputs and put them into a memory block and create a trigger logic to capture all the signals whenever any of the inputs changes, after lots of work and analysis, you will find the correct pins.
Anyway, these are just crazy ideas since this is a really difficult thing to do without having the PCB info of the board.
Good luck with your hacking.