My requirement is as follows:
I need to send Proximity Sensor (Reed Switches/Magnetic Sensor) reading (On/Off) from two Input Pins to a central PC.
I need to use coin cell. So basically the app should be in sleep mode and once there is any interrupt on any of these two pins it should wake up to send its state to the central PC.
I have DA18450 chip and development board (murata ZY type) with me.
Dialog Semiconductor 18450
Murata Bluetooth Smart Development Board
I am a beginner to bluetooth technology and started reading about it just a week back.
Could someone guide me about the most apt Profile/Service suitable for my application?
If you want the device to actually sleep then it'd probably be best for it to just transmit data via advertising packets when the device awakens. Otherwise you have to maintain a connection which requires staying awake at some level. However, advertising packets are broadcast and the device can't know if anything received those packets (you could have it broadcast several times for a fixed period of time or have it constantly broadcast while the proximity alert is valid). Also, on the receiving end, with no connection there's no way of knowing the transmitting device is even there when nothing is being transmitted.
The advertising packets have a section for limited information and that's where you'd transmit data if you don't want to establish a connection.
Related
I currently have an ESP32-S2 QT Py that I am using to send sensor data to a PC via wifi using TCP. I want to preserve battery life while not sensing, so I put it into deep sleep. I see that there are timer, pin, and touch alarms to wake it back up, but none of these work well for my design. Is there any way that I can wake up a deep sleeping ESP32-S2 with a TCP packet send from the PC server?
This functionality is commonly called "wake on LAN" and is generally used, as you described, to allow a "magic" packet to wake up a sleeping or hibernating device.
In this case, no. The ESP32's wifi radio is off during deep sleep. With the radio off there's nothing active that can receive or detect a packet.
If you're trying to conserve power and maximize battery life, you need to keep the radio off as it uses quite a bit of power just to stay connected to a wifi network.
The only parts of the ESP32 that are active and available during deep sleep are the ULP ("Ultra Low Power") processor, a very limited slow processor that can perform a few I/O actions during sleep, and a small amount of static RAM associated with the real time clock. You can learn more about the ULP and what it can do in Espressif's documentation.
I'm doing a security analysis project on an IoT device that uses an unencrypted BLE connection (with ATT protocol) and I want to spoof an individual BLE packet with the source address of an already connected device. Is there some tool or API that would allow me to do this easily? I've already tried gatttool and spooftooph but they seem to be connection based and don't allow you to send out single packets with modified fields (as far as I could tell).
You will need some hardware where you can access the radio peripheral directly. What you basically need to do is to find or write a ble sniffer firmware, with the modification that it at a given moment sends a packet on the connection it is currently listening to. But note that the signal strength must be stronger than the original device's signal so it doesn't interfere.
The only open source project I'm aware of is Ubertooth. You will also be able to do this with an nRF52 but then you need to write your own sniffer firmware since Nordic Semiconductor's is closed source.
I can't comment on Emils reply yet, < 50 rep:
Nordic Semis nRF Sniffer v2 needs only the nRF52DK and wireshark to work as a general BLE sniffer. At 40$ it's not that expensive. I know for a fact they will release a new dongle soon that will sell for ~10-15 bucks if you can wait a a month or two.
I am trying connect multiple Arduino Mega Boards via their Serial pins to allow communication between the boards. I want to be able to connect an arbitrary amount of arduinos by daisy-chaning them and I want one board to be the master, taking control over the actions of the other boards. The master should be determined dynamically by the boards. I am aware that the daisy chaining method introduces delays to the communication due to the forwarding of packets, but so far I am planning on connection 4 boards at most. In the future this might increase to maybe 10 boards. My boards all have a separate power source, since they are connected to some other hardware which has its own power source.
My idea was to connect the boards in such a way, that the master would be determined by the wireing of the boards. I thought about having the "Serial" port as 'To-Master' serial port and the "Serial1" port as "To-Child" serial port. The boards send hello messages on the "To-Master" serial port and the master replies if it received such a message on the "To-Child" serial port. If no answer is received after some seconds, the board determines itself to be the master.
I wired the boards up by connecting the ground pins, and wiring RX1 of the master to TX0 of the child and TX1 of the master to RX0 of the child:
Basically my setup is working, since the boards do detect each other and exchange hello messages and replies. There is however a significant amount of packet loss or corruption which I would like to eliminate.
As a simple measure of packet verification, I begin each packet with a "magic number". The receiving board looks for this byte and only tries to read a packet after receiving this byte. Any other bytes received are simply discarded.
As it seems, it happens quite often that something is received on either serial port that does not start with the magic number and is therefore discarded. The timestamps of these events are however consistent with the timestamps of sending of the other board meaning that the packet was at least partially transmitted but somehow the magic byte got corrupted or discarded.
Is this a known problem with the arduinos serial ports?
Can it be related to my wiring?
Are there any measures I can take to ensure a save delivery of the packets?
Can it be a problem of the boards not reading the signal at the correct time (I used a baud rate of 9600)?
I also looked into I2C communication, but I did not find any resource or information if it is possible to dynamically choose the master for this type of communication. Also in the documentation it stated, that it is important that all devices share a common power source which is not possible in my scenario. However, the basic master-slave principle of this I2C conforms with my requirements, as I have a master that sends commands to all other boards. Could I2C be utilized in my case?
Thank you for your thoughts!
Here is a discussion about multi-master I2C topology of Arduinos, seems that it is supported (haven't tested it myself). - http://forum.arduino.cc/index.php/topic,13579.0.html
You can test SPI as well, here is a comparison between the two - http://components.about.com/od/Theory/a/Selecting-Between-I2c-And-Spi.htm.
Slave might be selected with generic GPIOs
I don't know any known implementation of multi-clients on top of Serial bus (usually it is intended for peer2peer communication only) - even though, your configuration seems reasonable, I would be considering other options.
BTW, from your comment about different power sources, I assume your boards are away from each-other. Have you considered very cheap ($2) RF modules, such as nRF24L01+ (http://maniacbug.wordpress.com/2011/11/02/getting-started-rf24/). THere is a library for networking those in multi-node network
Might be better off with I2C or SPI like people have suggested here.
However, to address your question directly, it is most likely wiring. I am assuming you are using cheap jumper wires to plug directly into the Arduino Headers. Noise on this connection is the most likely problem or garbled serial messages. Try implementing with twisted pair cables and connecting directly to the board.
SPI or I2C might have better error correction than your customer serial protocol. I would see the other answers for that.
I read a lot about WiFi sensors being used to track smart phones in Retail environment. The location triangulation is done on basis that a smart phone has its WiFi turned ON, be it in connected or unconnected state.
Case 1 : WiFi turned ON but unconnected
Why should a smart phone which has its WiFi turned ON need to transmit the packets, unless the user 'scans' for nearby WiFi networks?
Case 2 : WiFi turned ON and connected
Why should a smart phone transmit any packets, unless the user is browsing the net?
In both the above cases, there is a high chance that most of the time the WiFi device does not send any packet, which means none of the WiFi sensors detect it. If that is true, then the whole idea behind WiFi sensor based triangulation in Retail goes for toss, clearly with so many companies working on this, I must be wrong. Please answer with more than a yes or no, as to which packets are generally sent in both the above scenarios.
If wifi is turned on it will periodically search for new networks. This happens even if you are already connected to one, as it allows the device to connect to a 'better' network, if available.
Scanning/network discovery can be done in two ways. First is passive when a device listens to surrounding access point's (AP) beacon frames. These are basically advertisements for their network. The second method is called active. This is the most likely explanation of how the technology you mentioned works. Active scanning is when the device sends out a probe frame asking for available APs. These are generally ones that you have associated with previously, e.g. Your home network. These probes can be listened to from nearby 802.11 (wifi) devices, therefore tracking you.
Active and passive scanning
801.11 frames
As mentioned in #AndrewLeeming answer, one of the causes for data transmission data is scanning.
It's not necessary but normally it will be performed to find a network to connect to (or a better network in case of already connected). Active scanning can be turned off for power saving reasons. Passive scanning doesn't involve transmissions, so it's irrelevant to this question.
However, the most important reason for WiFi devices to transmit packets while connected is to let the AP know that the client is still available. Otherwise the AP will drop the link after a certain period of time without activity. Additionally, the clients might be in power save mode and instruct the AP not to transmit data to them. From time to time the client will inquire the AP to see if there are any pending packets for it.
I currently have an embedded device connected to a PC through a serial port. I am having trouble with receiving data on the PC. When I use my PCI serial port card I am able to receive data right away (no delays). When I use my USB-To-Serial plug or the motherboards built in serial port I have to delay reading data (40ms for 32byte packets).
The only difference I can find between the hardware is the UART. The PCI card uses a 16650 and the plug/motherboard uses a standard 16550A. The PCI card is set to interrupt at 28 bytes and the plug is set to interrupt at 14 bytes.
I am connected at 56700 Baud (if this helps).
The delay becomes the majority of the duty cycle and really increases transfer time. (10min transfer vs 1 hour transfer).
Does anyone have an explanation for why I have to use a delay with the plug/motherboard? Can anyone suggest a possible solution to minimizing or removing this delay?
Linux has an ASYNC_LOW_LATENCY flag for the serial driver that may help. Whatever driver you're using may have something similar.
However, latency shouldn't make a difference on a bulk transfer. It should add 40 ms at the very start of the transfer and that's it, which is why drivers don't worry about it in the first place. I would recommend refactoring your transfer protocol to use a sliding window protocol, with a window size of around 100 packets, if you are doing 32-byte packets at that baud rate and latency. In other words, you only want to stop transmitting if you haven't received an ACK for the packet you sent 100 packets ago.
You'll probably find that different USB-Serial converters produce different results. We've found that the FTDI ones work well for talking with embedded devices. Some converters seem to buffer the data for a long time and/or fragment it.
I've never seen a problem with a motherboard connection - not sure what is going on there! Can you change the interrupt point for the motherboard serial port?
I have a serial to usb converter. When I hook it up to my breakout box and create a loopback I am able to send / receive at close to 1Mbps without problems. The serial port sends binary data that may be translated into ascii data.
Using .Net I set my software to fire an event on every byte (ReceivedBytesThreshold=1), though that doesn't mean it will.