How could I change the value of variables that were set at the factory? I want to change the calibration of my cycling power meter which uses the https://www.bluetooth.com/specifications/specs/cycling-power-profile-1-1/ BLE cycling power profile. I could also maybbe change the crank length to adjust the power readings.
I can connect to the device by nrf connect and write to the device.
Related
I have 3 XBee SMT Grove Development Boards. I configured two of them as coordinator and endnode respectively. Note that the end node is not connected to any intelligent computer via its serial interface. It is simply powered on and is configured to read an analog sample at regular intervals and transmit it to the coordinator.
My intension is to connect an analog sensor (example: Rotary angle sensor) and transmit the knob position at regular intervals to the coordinator (using the IO data sample indicator frame).
I connected the sensor to the AD3 slot of the end node. And end node reads a sample of data and successfully sends this value to the coordinator at regular intervals. However I noticed that for a position of approximately 0-150 degrees, the IO sample value as received at the coordinator seems to be (21-1023). Meaning, the value changes according to the knob position. But when I move the knob position further (the supported rotation range by the sensor is 0-300 degrees), from 150-300 degrees, I notice the value always remains constant(1023).
I know that 2 bytes of analog samples can be transmitted via this frame. And the IO sample of the sensor is also 2 bytes. So I am wondering why the value remains the same for half the position of the rotary where as for the first half it changes as expected ?
Please note that the sensor is already tested on a Grove Pi+ shield on a Raspberry Pi for correctness using the example code. It works perfectly throughout the whole range.
Thank you all for your time.
I'm trying to find the RSSI value for a phone that is connected to my laptop by Bluetooth. I use the below command on Ubuntu:
hcitool rssi AA:BB:CC:DD:EE:FF
But I get this:
RSSI return value: 0
But I want the value in the range of -20 to -100 for example.
How can I solve this problem?
The HCI tool doesn't retrieve data directly from your radio, rather it uses the standardized Bluetooth HCI (host-controller interface). The definition of the read RSSI HCI command, from the spec:
7.5.4 Read RSSI command
Description:
This command reads the Received Signal Strength Indication (RSSI) value
from a Controller.
For a BR/EDR Controller, a Connection_Handle is used as the Handle
command parameter and return parameter. The RSSI parameter returns the
difference between the measured Received Signal Strength Indication (RSSI)
and the limits of the Golden Receive Power Range for a Connection_Handle to
another BR/EDR Controller. The Connection_Handle shall be a
Connection_Handle for an ACL connection. Any positive RSSI value returned
by the Controller indicates how many dB the RSSI is above the upper limit, any
negative value indicates how many dB the RSSI is below the lower limit. The
value zero indicates that the RSSI is inside the Golden Receive Power Range.
Note: How accurate the dB values will be depends on the Bluetooth hardware.
The only requirements for the hardware are that the BR/EDR Controller is able
to tell whether the RSSI is inside, above or below the Golden Device Power
Range.
The RSSI measurement compares the received signal power with two
threshold levels, which define the Golden Receive Power Range. The lower
threshold level corresponds to a received power between -56 dBm and 6 dB
above the actual sensitivity of the receiver. The upper threshold level is 20 dB
above the lower threshold level to an accuracy of ±6 dB.
So basically the reason you're seeing "0" is because your device is within the "golden range" as configured in the hardware driver. You will not be able to get a more accurate reading using HCI commands
I noticed two blocks in InvenSense SensorStudio which appear to be very similar. hey are AuxillarySensorDesign (driver) and CustomSensorDesigner block. What is the difference between the two?
AuxilliarySenorDesigner
Connect to device block (and not to sensor block)
Does not support emulation
Must be used to create driver sensors that get data from hardware (I2C)
CustomSensorDesigner
Connect to one or several sensors block
Support emulation
Should be used to create virtual sensors that gets data from other sensors in the system and apply some algorithm
CustomSensor
Connect to device block
Used to retrieve sensor data from custom sensors from the device (after flashing a firmware)
Refer to "3.6. DESIGN YOUR SENSOR ALGORITHM", "3.7. SENSOR FRAMEWORK EXPLAINED" and "3.8. DESIGN YOUR SENSOR DRIVER" of 001 - SensorStudio User Documentation.pdf available with your SensorStudio installation
Hi I have a SPI touch device with 24 keys, each read will return 3 bytes, containing exact all 24 keys status. My hardware is a custom made beaglebone like device, spi0 is able to read its own write by connecting MISO to MOSI.
Everything (wiring, software) is working perfectly matching this guide: http://communistcode.co.uk/blog/blogPost.php?blogPostID=1
Now my touch device is CS active high device, but it requires to drive the chip select to low and back to high before actual read. I don't seems to have control with SPI cs value, I can only either control it within an actual read phase by specifying CS high or low. From my knowledge I have to use another GPIO to emulate the CS.
Question: any way to control cs freely? (i.e. set 0 or 1 by my code directly?)
I have solved this by pinmux the CS pin to a GPIO, and control it manually prior to actual communication.
Hello there I am a newbie trying to prove the working of RS 232 Full modem and also one RS 422( RX,TX,RTS,CTS)
These 2 ports are on a custom designed board and I need to prove they are working.
I am able to confirm the working at register level but I need to prove the working using softwares like Minicom or any other custom program.
How can I prove the working of these ports from one PC to a different PC using DB 9 connections and LOOP BACK too
Can someone help me with this? Do I need to use any extra hardware to prove the working of this in Linux?
The most common type of serial port test is probably a loopback test. Create a test fixture that connects output pins of the port to the input pins (TX->RX, RTS->CTS, etc). If you do not have matching input pins for every output pin, you will need to do a three-way connection.
After you create the loopback, you will need to write software that exercises the pins. If TX and RX are connected, you can send a byte and verify that it was echoed back. For the control pins, toggle them and make sure the other side of the connection saw the transition. Make sure you exercise every pin of the serial port.
Note that you should run a TX->RX data loopback at multiple baud rates. It is possible for there to be a signal integrity issue in the design that only shows up at higher bauds rates. It is also possible for there to be a bad signal connection on the board that is masked by inductance and capacitance at higher baud rates. Therefore, it is a good idea to run a data loopback at the slowest baud rate, the fastest baud rate, and 1-2 in the middle.
Another thing you should do is a baud rate accuracy test. This will prove the clock driving the UART is running at the right frequency, and being divided properly. Transmit X amount of bytes at a certain baud rate and verify they arrived in the expected amount of time. To get an accurate number, you will need to bypass any buffering in the OS serial port driver (e.g. use direct register I/O), and make sure to accommodate for any start/stop bit overhead (see comments below).
However, a loopback test is not exhaustive. It only proves the device can talk to itself. The device may still have some flaw (e.g. voltage levels) that cannot be detected locally. So, you should also run some tests with external hardware. Cable your board to another system and run a test (e.g. with minicom). Make sure they can talk to each other.
Even an external communication test can miss something. You can still have poor signal quality from your board, but it happens to be good enough for the other device. To accurately verify the signal quality/timing, you need an oscilloscope.
While you are running communication tests, connect the scope probes to the various signals and verify the signal integrity. Make sure that voltage levels are valid, that you see clean low/high bit transitions, and that the timing of the data pin appears correct for the specified baud rate. (A scope can be a more accurate way to measure baud rate than the software-based method described earlier.)