I'm currently trying to interface a cs5530 ADC to a raspberry pi 4b 8g using SPI. When I attempt to communicate with the ADC I repeatly get return bits that make no sense and am running out of ideas to trouble shoot. When using the Spidev-test script I'm recieving the following response:
spi mode: 0x4 bits per word: 8 max speed: 2000000 Hz (2000 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF F0 0D
RX | FF FF FF FF FF FF FF F8 00 00 00 27
F8 00 00 00 27 F8 00 00 00 27 FF FF FF FF FF FF FF FF FF FF
As you can see there's something causing the MISO line to be recieving incorrect bits. If I use a jumper from MOSI to MISO to the bits return as should be expected. I've tried different clk speeds while staying under 2MHz as that is specified as the max clk speed in the cs5530 data sheet. I'm also recieving similar junk back using the spidev libary in python.
I'm thinking the most likely problem I have is for some reason the clk on the rpi isn't producing a proper signal. I don't own a logic analyser (thinking I'll properlly have to order one) so I've mapped the signal the best I can using piscope.
this image shows what looks like to me the clk line not functioning as you should expect.
I'm a novice at this sort of thing but it looks to me that the clk line is all over the show instead of regular sine wave you'd expect to see there. I'm not sure if this is what's casuing me issues or if it's due to the limitations of piscope.
this image also shows similar behaviour happening when I'm shorting MOSI and MISO to test the lines.
So while I think I've found the cause of my issues I'm about out of ideas of what could be causing this issue and how to fix it. So far all the things I've tried when trying to troubleshoot this is:
Swapping out Raspberry Pi's - Problem presists exactly the same.
Swapping out cs5530
checked all my solders on the prototyping board and continuity between all points, test resistor values and cap's are all at correct values. Swapped crystals due to not having a scope to test it.
Tested the cs5530 at both 3v and 5v modes (using an external power supply)
Grounded rpi to external power supply
Tried running a cs5530 off rpi 3.3v supply
set core_freq=250 on rpi
set dvfs=2 to rpi to prevent any issues caused by core being under voltaged
tested on spi0 (CE 0 and 1) and spi1
temp was 53 degrees when the tests in the pictures where done so I think I can rule out thermal throttling as well. At this point I'm completely out of ideas what else to try. Might be worth noting that I am booting off a high quality 16gb USB flash drive, I haven't bothered coping the img to a sd card just yet as I wouldn't have thought that this would be causing any problems but I might try it just to fully rule that possiblity out.
link for cs5530 datasheet : Cs5530 Datasheet
Thanks in advance for any help, hoping that there's someone much smarter than me out there that can shine some light on this for me.
Cheers
I am a hardware guy with little embedded systems experience, so my question may be trivial.
I need to put an Ethernet switch in "test mode 1" which is an Ethernet compliance test mode you can put the chip in for characterizing signals on a scope. at the bottom is the datasheet page that shows this register and how to put it in test mode 1.
I am using u-boot i2c commands to do this.
chip Slave address = 0x5F
Port 1 address (to be written to) = 0x1112.2 (16 bit address needs the .2, correct me if i am wrong)
I send the following command to the switch:
#i2c mw 0x05F 0x1112.2 0x01 10
Then I read it back:
#i2c md 0x05F 0x1112.2 10
1112: 01 00 00 00 00 00 00 00 00 00 00 00 30 00 00 00 ............0...
The command that I am writing is only writing to the first bit. I cant for the life of me figure out how to write to any other bit at that address other than the first one. What would my u-boot i2c command look like if I wanted to set bits [15:13] to [0 0 1]?
I want to communicate my android app to this smart band (T1S), I've already paired it, but I don't know how to extract data from it, such as temperature, etc.
I got the characteristics and services from it:
{"name":"T1S","id":"F4:C3:33:99:21:5D","advertising":{},"rssi":-78,"services":["1801","1800","6e400001-b5a3-f393-e0a9-e50e24dcca9e","1812","fee7"],"characteristics":[{"service":"1801","characteristic":"2a05","properties":["Broadcast","Read","Write","Notify","Indicate","AuthenticateSignedWrites"],"descriptors":[{"uuid":"2902"}]},{"service":"1800","characteristic":"2a00","properties":["Read"]},{"service":"1800","characteristic":"2a01","properties":["Read"]},{"service":"1800","characteristic":"2a02","properties":["Read"]},{"service":"1800","characteristic":"2a04","properties":["Read"]},{"service":"1800","characteristic":"2aa6","properties":["Read"]},{"service":"6e400001-b5a3-f393-e0a9-e50e24dcca9e","characteristic":"6e400003-b5a3-f393-e0a9-e50e24dcca9e","properties":["Notify"],"descriptors":[{"uuid":"2902"}]},{"service":"6e400001-b5a3-f393-e0a9-e50e24dcca9e","characteristic":"6e400002-b5a3-f393-e0a9-e50e24dcca9e","properties":["WriteWithoutResponse","Write"]},{"service":"1812","characteristic":"2a4e","properties":["Read","WriteWithoutResponse"]},{"service":"1812","characteristic":"2a4d","properties":["Read","Write","Notify"],"descriptors":[{"uuid":"2902"},{"uuid":"2908"}]},{"service":"1812","characteristic":"2a4d","properties":["Read","Write","Notify"],"descriptors":[{"uuid":"2902"},{"uuid":"2908"}]},{"service":"1812","characteristic":"2a4d","properties":["Read","Write","Notify"],"descriptors":[{"uuid":"2902"},{"uuid":"2908"}]},{"service":"1812","characteristic":"2a4b","properties":["Read"]},{"service":"1812","characteristic":"2a33","properties":["Read","Write","Notify"],"descriptors":[{"uuid":"2902"}]},{"service":"1812","characteristic":"2a4a","properties":["Read"]},{"service":"1812","characteristic":"2a4c","properties":["WriteWithoutResponse"]},{"service":"fee7","characteristic":"fec9","properties":["Read","Notify"],"descriptors":[{"uuid":"2902"}]},{"service":"fee7","characteristic":"fea1","properties":["Read","Indicate"],"descriptors":[{"uuid":"2902"}]},{"service":"fee7","characteristic":"fea2","properties":["Read","Write","Indicate"],"descriptors":[{"uuid":"2902"}]}]}
I've analyzed another android apps and I captured received and sended bluetooth data with this smart band and my phone with Wireshark and bluetooth-log to know what data or protocols are transmitted to get the temperature, I'm sure that the response of temperature is:
0000 02 02 20 14 00 10 00 04 00 1b 12 00 ab 00 0a ff ..
............. 0010 51 13 14 06 05 06 37 24 05
Q.....7$.
But I don't know how to convert this response to actual temperature in C°, somebody knows how to extract the real data from this smart band?
thanks in advance.
smart band link:
https://www.alibaba.com/product-detail/Cheap-High-Quantity-Bluetooth-Smart-Bracelet_1600057978967.html?spm=a2700.icbuShop.111720.6.54226ef9FPTgvq
const readCharacteristic = await device.readCharacteristicForService(userDataServiceUUID, heightCharacteristicUUID); // assuming the device is already connected
const heightInCentimeters = Buffer.from(readCharacteristic.value, 'base64').readUInt16LE(0);
https://github.com/Polidea/react-native-ble-plx/wiki/=--FAQ:-Passing-And-Retrieving-Of-Characteristic-Value
I have those 3 Events in a Midi file:
00 FF 51 03 0E 15 C3 86 A6
20 FF 51 03 15 20 A5 83
5C FF 51 03 0E 15 C3
But what is, in this case, important is, that FF 51 stands for a Tempo Change and the 03 for the number of following Byte-Pairs describing the tempo. As it is "3 Byte Pairs" in Each Event Why are there 5 Byte Pairs describing the first Event, 4 describing the second, and 3 describing the third? (I hope the image helps)
How does the encoding program know, when a new Event starts? The File can be played without any Problems.
All three events have three data bytes.
The delta times between the events are encoded as variable-length quantities, so you have to continue to read bytes until the most significant bit is clear. The three times before each event are 00, 86 A6 20, and 83 5C, resulting in the decoded delta times of 0, 109344, and 476.
I have integrated a TI lib for .h264 encoding on davinci board with processor dm6446
I could verify the encoded bit stream when saved on hdd and using Elecard stream analyser.
But i could not stream it over rtsp and view in vlc player. The VLC player would switch to TCP/IP and then stop showing message as nothing to play. On further debugging i found out that each encoded bit stream generated is of type IVIDEO_IDR_FRAME .
The Nal header for each frame is like
00 00 00 01 67 42 80 1E DA 05 c7 D9 74 00 00 00 01 68 CE 3c 80 00 00 00 01 65
As I understand 00 00 00 01 are used as a delimiter and 67 and 68 are for SPS and PPS respectively. After streaming first two frames as is, I tried to stream the next frames from the data 00 00 00 01 65. But still VLC player could not play the encoded stream. It showed the message at found PPS and stoped there.
What should i do to resolve this issue. I am quite newbee to this field