How would you access gps information (say latitude, longitude) from the internal gps receiver with a gps antenna connected to a USRP E312? I'm using python2 generated by gnuradio for all of my code. I'm thinking maybe there's a command I can call from the uhd.
On the E310 itself, the GPS module is handled by gpsd, which should be part of the image you're running. You should be able to interface with that using libgps. You could use the gpspipe tool to test:
gpspipe -w
Related
We are using two USRPs and GNU Radio Companion to build an OFDM radar. The first USRP is the N210 which is used as a transmitter through its Tx/Rx port. The second USRP is N200 which is used as a receiver through its Rx2 port. They are connected together through the so-called MIMO cable to synchronize them. The N210 is connected to the host PC through the gigabit Ethernet cable. The samples that feed the transmitter USRP comes from a block "File Source", and the samples that are collected from the receiver USRP goes to a block "File Sink".
Initially, an external loopback cable is used between the Tx/Rx port of N210 and the the Rx2 port of the N200. Whenever we run the flowgraph, we expect that for every sample that is transferred from the File Source to N210, there should a corresponding sample with somehow same value that comes from N200 to File Sink. However, we have noticed that the N200 produces a stream of random samples before the awaited samples start to appear!!! The length and the values of this stream of random samples varies each time we re-run the flowgraph!!! Of course this issue constitutes an obstacle for our application because in radar the range of the target to be detected is estimated depending on the delay time. The latter is computed from the number of noise samples at the receiver that precedes the reception of the actual transmitted samples.
The question is: How can we guarantee or force the receiving USRP (N200) not to receive any sample before the transmitter USRP (N210) starts to transmit the required samples? Should not this be the task of GnuRadio?!!!! or we have to do something in GnuRadio to force this to happen?
thnx
We are using two USRPs and GNU Radio Companion to build an OFDM radar. The first USRP is the N210 which is used as a transmitter through its Tx/Rx port. The second USRP is N200 which is used as a receiver through its Rx2 port.
This sounds like you're reproducing my 2013 bachelor thesis!
Whenever we run the flowgraph, we expect that for every sample that is transferred from the File Source to N210, there should a corresponding sample with somehow same value that comes from N200 to File Sink.
No, that would only work when you start and stop both USRPs using the same command times and the same number of samples to be acquired.
However, we have noticed that the N200 produces a stream of random samples before the awaited samples start to appear!!!
Well, over-the air delay, and the state in the DSP chain. This is expected. Use timed commands to make the timing deterministic, and you'll know how many samples to ignore.
I have ESP23 dev kit with micropython firmware esp32-idf3-20200329-v1.12-317-g688323307.
I also have ds18b20 waterproof sensor. datasheet link
I wrote this code for it:
import time, onewire, ds18x20
import machine
from machine import Pin
ds_pin=Pin(19)
ds_sensor = ds18x20.DS18X20(onewire.OneWire(ds_pin))
roms = ds_sensor.scan()
for rom in roms:
print(rom)
It returns tis info:
[bytearray(b'(\xbcN6\x14\x19\x01\xba')]
Before reading temp data from sensor, we first need to use the scan() function to scan for DS18B20 sensors. The addresses found are saved on the roms variable (the roms variable is of type list). scan() function sends request and sensor returns its unique 64-bit serial code.
I used manual here
Today I bought two more ds18x20 waterproof sensors (I don’t know what type of sensor - ds18a20/ds18b20 or else - are they, ‘cause eager chinese manufacturers sealed sensors inside metal bullet too good, so I can’t just look inside).
I tried to run the same code with them, but it returned the following:
bytearray(b'(\xff\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xfe\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xfc\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xf8\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xf0\xff\xff\xff\xff\xff\xff')
bytearray(b'(\xd0\xff\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xff\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xfe\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xf6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xe6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\xc6\xff\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xff\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xfd\xff\xff\xff\xff')
bytearray(b'(\x90\x86\xf9\xff\xff\xff\xff')
bytearray(b'(\x90\x86y\xff\xff\xff\xff')
bytearray(b'(\x90\x86y\xfe\xff\xff\xff')
bytearray(b'(\x90\x86y\xfa\xff\xff\xff')
bytearray(b'(\x90\x86y\xf2\xff\xff\xff')
bytearray(b'(\x90\x86y\xe2\xff\xff\xff')
bytearray(b'(\x90\x86y\xa2\xff\xff\xff')
bytearray(b'(\x90\x86y\xa2\xfd\xff\xff')
bytearray(b'(\x90\x86y\xa2\xf9\xff\xff')
bytearray(b'(\x90\x86y\xa2\xf1\xff\xff')
bytearray(b'(\x90\x86y\xa2\xe1\xff\xff')
bytearray(b'(\x90\x86y\xa2\xc1\xff\xff')
bytearray(b'(\x90\x86y\xa2\x81\xff\xff')
bytearray(b'(\x90\x86y\xa2\x01\xff\xff')
bytearray(b'(\x90\x86y\xa2\x01\xfb\xff')
bytearray(b'(\x90\x86y\xa2\x01\xf3\xff')
bytearray(b'(\x90\x86y\xa2\x01\xe3\xff')
bytearray(b'(\x90\x86y\xa2\x01\xc3\xff')
bytearray(b'(\x90\x86y\xa2\x01\x83\xff')
bytearray(b'(\x90\x86y\xa2\x01\x03\xff')
bytearray(b'(\x90\x86y\xa2\x01\x03\xfe')
bytearray(b'(\x90\x86y\xa2\x01\x03\xfc')
bytearray(b'(\x90\x86y\xa2\x01\x03\xdc')
bytearray(b'(\x90\x86y\xa2\x01\x03\\')
When I try to read temperature using this values it returns ‘CRC error’.
What can be done? Is the problem with code, or the sensors are failed somehow?
Connect one sensor at a time when you do the scan.
You haven't shared how you're wired the DS18x20 sensor. Make sure its positive power connection is to 3.3V not 5V.
Make sure you've connected a resistor (4.7K should be good) between the data pin of the sensor and 3.3V. OneWire devices absolutely won't work reliably without this resistor - you might see the kind of problem you're seeing.
If you're sure it's wired correctly the next step would be to try it with different firmware, for instance a Dallas one-wire scanner using the Arduino Core. That would eliminate the possibility of problems with the library you're using and MicroPython.
looks like fake sensor
How to tell original from fake DS18B20 temperature sensors
Looks like i'm a fool))
Yes. One 4.7K pull up resistor and it's alive! IT'S ALIVE!!
aaaand whats'up doc?
then we use internal PULL_UP mode we pull up signal only for ESP.
BUT! DS18B20 is microchip too. And the wire for little DS18B20 is like giant radio aerial.
Maybe in my first sensor this problem was solved on hard level.
I'm eventually trying to use transparent data transmission to pass messages between the mobile SDK and an onboard device using the A3 API/UART port.
Right now I used DJI assistant to output a timestamp to the API port at 1hz. When I connect a TTL>USB device, I see garbage data coming through. When I connect an oscilloscope with a protocol analyzer, I see one frame every second, but the frame is variable size. The ASCII representation of what does come through is nonsense.
I have double checked that baud is set correctly (and have tried other baud rates). I've made sure the grounding is proper. I've tried probing the pin on the actual A3 port (to remove possibility of EMI on the serial cable). It seems like I'm getting garbage data on the serial line, or I don't know how to decode it properly.
Hi，maybe you can refer to the open-protocol of M100 Link.I think it's difficult to decode the protocol of N3,unless DJI publishes that。
I'm trying to implement S-MAC protocol on waspmote xbee sensors and i know it has its own CSMA/CA. So first of all I need to understand the basic of xBee collision avoidance.
Two senders set up in api mode in libraries and both periodically sending single bytes to a common receiver. I reduce the delay and many changing in libabries to make collision and to see how algorithm works. But when i monitor data at the receiver all looks as expected at the receiver .. byte1, byte 2 .. byte1, byte2.
Do u have any idea how can i make collision?
Are you sniffing the 802.15.4 traffic? That's the only way you'd see a collision.
The XBee module buffers the data you want to send, using the host communication parameters (baud rate, API mode, etc.) and then sends it out over 802.15.4 at 250kbps. The module has all of the collision avoidance built in, and will retransmit as necessary to deliver your message. If it's unable to deliver after some number of transmission attempts, you'll get a Transmit Status frame indicating failure.
On the receiving end, it buffers the data and delivers it to the local host using local serial settings (baud rate and API mode).
If you're trying to implement S-MAC, you need a different radio processor where you have low-level control over the radio. The XBee module provides an application layer and handles the MAC layer itself.
I have to dash away from the computer frequently, and I want to trigger some commands to run when my iPhone is close enough/far enough from my iMac (next to it vs. 2-3 metres away/other side of a wall). A couple of minutes latency is fine.
Partial solution: proximity
I've downloaded reduxcomputing-proximity and it works, but this only triggers when the device goes in to/out of range of bluetooth, but my desired range is much smaller.
(Proximity polls [IOBluetoothDevice -remoteNameRequest] to see if the device is in bluetooth range or not.)
Enhancement: rawRSSI
I've used [IOBluetoothDevice -rawRSSI] to get the RSSI when I am connected to the iPhone (when disconnected this just returns +127), but in order to save the battery life of my iPhone I'd rather avoid establishing a full bluetooth connection.
Am I correct in thinking that maintaining a connection will consume more battery life than just polling every couple of minutes?
I've overridden the isInRange method of proximity here to give me a working solution that's probably relatively battery intensive compared to the previous remoteNameRequest: method:
- (BOOL)isInRange {
BluetoothHCIRSSIValue RSSI = 127; /* Valid Range: -127 to +20 */
if (device) {
if (![device isConnected]) {
[device openConnection];
}
if ([device isConnected]) {
RSSI = [device rawRSSI];
[device closeConnection];
}
}
return (RSSI >= -60 && RSSI <= 20);
}
(Proximity uses synchronous calls - if and when I fit it to my needs I will edit it to be asynchronous but for now that's not important.)
Under Linux: l2ping - inquiry scan?
This SO post references getting an RSSI during an 'inquiry scan' which sounds like what I want, but it talks about using the Linux Bluez library, whilst I am on a Mac - I'd rather do it without having to stray too far if possible! (I have considered using a VM with USB pass-thru to hook up a second bluetooth device... But a simpler solution would be preferable!)
I see there is a IOBluetoothDeviceInquiry class, but I am not sure if this is useful to me. I don't intend to learn bluetooth protocol just for this simple problem!
The commands
For interest, and not particularly relevant to the solution, here are the Apple Scripts I currently trigger when
in range:
tell application "Skype"
send command "SET USERSTATUS ONLINE" script name "X"
do shell script "afplay '/System/Library/Sounds/Blow.aiff'"
end tell
out of range:
tell application "Skype"
send command "SET USERSTATUS AWAY" script name "X"
do shell script "afplay '/System/Library/Sounds/Basso.aiff'"
end tell
Though these are likely to get longer!
You are correct that making a connection will cost more energy. However, I'm not aware of APIs on mac OS that will give you access to the RSSI from inquiry scan packets. You could get access to the raw packets from your BT adapter using Mac OS PacketLogger. See this post Bluetooth sniffer - preferably mac osx
You could programmaticly put your device in discovery every couple of minutes, capture the inquiry scan packets with the packetlogger, and parse out the RSSI. You can use WireShark to help you understand how to decode the packets and find RSSI.
Your simplest option is probably to just periodically create a connection, measure RSSI, and then tear down the connection.
In terms of tradeoffs for your use case doing a continuous or periodic inquiry will consume same or even a bit more energy as doing a periodic connect / read RSSI and disconnect. Depending on the use case it sometimes may be more efficient to maintain the connection in a low power mode (sniff with 2.56 sec interval) and remain connected if the device is in range. And use RSSI to monitor proximity (although it is not accurate as interference due to objects change rssi drastically even though the device might be in proximity)