is the slaesh cc2652RB stick supported? about sniffle HOT 17 CLOSED

Hi @mh-, I don't have this dongle with me at the moment, but according to my notes:

1. I did not need to build myself firmware from sources, just used sniffle_cc1352p1.out (version 1.6) from github releases. Note: DO NOT USE the latest 1.7 as it disables USB bootloader and you would have to connect jtag directly for the next flash. But if you built the latest sources from github, including this patch that leaves our USB bootloader intact: ed55da3, you should be OK.
2. I converted the .out to bin using this command: objcopy -I elf32-little -O binary sniffle_cc1352p1.out sniffle_cc1352p1.bin
3. I flashed using cc2538-bsl script. Hold the "BSL" button while plugging in via USB and then: python3 cc2538-bsl.py -evw sniffle_cc1352p1.bin. I haven't tried thie ZigStar tool for flashing.

Also, according to my notes I did not need to alter this rts/dtr for this dongle.
Hope it helps

from sniffle.

Yes, I can confirm that I do not see lost packets in that scenario at 921600 baud with the Launchpad.

Please note that many custom boards may require a different XOSC_CAPARRAY_DELTA value. An incorrect value can cause packet loss.

from sniffle.

I got a version of this stick which has a Silicon Labs CP2102 (apparently not a CP2102N) USB-to-serial chip populated, this has a maximum baud rate of 921,600, not 2,000,000.
@sultanqasim Do you think this baud rate might be sufficient? Or what would be a good test to find the minimum required baud rate?

from sniffle.

From my experience, 921600 baud should work fine for nearly all situations. There might be some exceptional situations that could saturate it when using the 2M PHY with raw L2CAP sockets trying to maximize data throughput in both directions, but I've never encountered that myself.

from sniffle.

Ok, I can confirm now that this CC2653RB stick works to some extent.

I had to change the baud rate in messenger.c to

int messenger_init()
{
    (...)
    uartParams.baudRate = 921600;
    (...)
}

then built the firmware, then flashed it using the recommended tool:

% arm-none-eabi-objcopy -O binary ~/Sniffle/fw/sniffle.out sniffle.bin
% ./cc2538-bsl.py -p /dev/tty.usbserial-14210 -evw sniffle.bin

Of course I also had to change the baud rate in sniffle_hw.py to

class SniffleHW:
    def __init__(self, serport):
        (...)
        self.ser = Serial(serport, 921600)

BUT:

I'm experiencing a lot of lost packets.

For example:

Timestamp: 11.790924	Length: 29	RSSI: -61	Channel: 28	PHY: 1M	Event: 35
LLID: LL DATA
Dir: S->M NESN: 1 SN: 1 MD: 1 Data Length: 27
[...]

Timestamp: 11.791371	Length: 2	RSSI: -51	Channel: 28	PHY: 1M	Event: 35
LLID: LL DATA CONT
Dir: M->S NESN: 0 SN: 1 MD: 0 Data Length: 0    
09 00

Timestamp: 11.817981	Length: 2	RSSI: -54	Channel: 27	PHY: 1M	Event: 36
LLID: LL DATA CONT
Dir: M->S NESN: 1 SN: 0 MD: 0 Data Length: 0
05 00

[...there's one packet missing here...]

Timestamp: 11.818211	Length: 11	RSSI: -62	Channel: 27	PHY: 1M	Event: 36
LLID: LL DATA
Dir: S->M NESN: 1 SN: 1 MD: 0 Data Length: 9
[...]

(I tried to use a USB extension cord for the stick, and different antenna orientations, but that didn't help either.)

Switching back to the LP-CC2652RB TI Launch Pad board, and changing nothing else (except for the baud rate, back to 2000000), all the packets were properly sniffed. Maybe the RF part is better on the TI board. (For reference, I ordered the stick with external antenna "Type 1".)

Also, I wasn't able to get a response from the seller, neither through the proposed Telegram contact, nor by e-mail, and it looks like I'm not the only one who experienced this, and so I will move on and try another stick.

from sniffle.

Yeah, that sounds like an RF signal quality issue to me. You could try the 921600 baud firmware on the Launchpad, I’m pretty sure that will work fine. I’ve actually been using Sniffle firmware built to use 200k baud (instead of 2M baud) to work around a latency issue in the XDS110 USB-UART bridge and that has been working fine for me without any loss in ordinary (low throughput) connections. If the baud rate is too slow, the transmit buffer in the firmware could overflow, and that could cause packet loss, but I don’t think that would happen at 921600 baud.

from sniffle.

Yes, I can confirm that I do not see lost packets in that scenario at 921600 baud with the Launchpad.

from sniffle.

Hi!
I've been playing with this stick for some time now, and I just noticed you made (almost) the same changes of baud rate as me :)
I also had to disable DTR and RTS in sniffle_hw.py:

   self.ser = Serial(serport, 921600)
   self.ser.dtr = 0
   self.ser.rts = 0

As the maker states:

The RTS signal is connected to the RESET-Pin and DTR is connected to the Bootloader_Enable-Pin!
If you dont wan't this behavior, you can destroy/cut the solder-pads underneath..

Without the above changes it did not work at all for me (I did not get anything on serial console). Did you cut the solder-pads in your stick?

I did not experience any "packet missing" issues at all in my case.
If you can provide a more detailed test case (maybe the BLE packets that are causing problems?) I can try to reproduce it in my environment.

By the way - @sultanqasim would you consider adding fw build options for this stick (and maybe others I am testing), for example as a separate PLATFORM? And also adding baud rate as a parameter to command line python?

from sniffle.

I didn't do any HW modifications, so apparently DTR and RTS have the right levels on my stick. I did have to use ./cc2538-bsl.py -p /dev/tty.usbserial-14210 -evw sniffle.bin to flash the firmware, which apparently uses DTR and RTS(?)

In my use case, I listen to a BLE connection between an iPhone SE 2020 and a Tuya BLE device, which uses PHY: 1M.

from sniffle.

The cc2538-bsl.py is using DTR and RTS lines to control bootloader:
https://github.com/JelmerT/cc2538-bsl/blob/0daa5d0980eae6a9eb58693c05503fdf6538703b/cc2538-bsl.py#L219-L222
that is why you don't need to press the button to program it.
I had to change also the sniffle_hw.py - otherwise the dongle was in boot mode and did not output anything on the serial console. I'm not sure why it did work for you without these changes. Maybe applying them would help to your issue?

I don't have Tuya BLE devices, but I have lots of devkits with various chipsets. Which chipset is in your Tuya BLE device? I have just tested it against my sample ESP32-C3 devkit LE 1M and I was able to sniff all the packets.

from sniffle.

@jslawek this is good news! I would be happy to wait for the necessary updates to the scripts and a firmware to make it into the repo and then buy a stick for this.

If there is any better stick, I would also be interested where to get it.

I have a working sniffLE on the launchpad, but thats just not handy enough for my EDC bag ;)

from sniffle.

My preferred one is ZigStar Stick V4, but there seems to be some kind of shortage currently. Based on CC2652P (you just flash the CC1352P fw image without any modification) + CH341a (handles 2000000, no need to downgrade the baud rate).

from sniffle.

My preferred one is ZigStar Stick V4, but there seems to be some kind of shortage currently. Based on CC2652P (you just flash the CC1352P fw image without any modification) + CH341a (handles 2000000, no need to downgrade the baud rate).

@jslawek any other hints how the setup works smoothly for the ZigStar Stick V4, e.g. which flashing tool do you use?

from sniffle.

I built the firmware for the ZigStar Stick v4 like this:

make clean
make PLATFORM=CC1352P1F3
arm-none-eabi-objcopy -O ihex sniffle.out sniffle.hex

and used the ZigStar GW Multi Tool to flash that hex file.

sniffle_hw.py required the changes mentioned above, to disable HW flow control, so that the chip would not be held in reset all the time.

Then this worked:

./scanner.py -s /dev/ttyUSB0 

but with some lost CRLF bytes when run inside a Linux VM.

from sniffle.

I bought a Sonoff CC2652P stick off Amazon, with the CP2102N USB-UART adapter. When I have time, I’ll build for it and either implement a baud rate option or automatic baud rate selection when the CP2012N is selected.

from sniffle.

Based off information at https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin, the CC2652P Launchpad compatible version of the firmware should also work on the Slaesh CC2652RB dongle, provided that the baud rate is supported by the CP2102 USB/UART adapter. With de7e919 I introduced a firmware variant with a 1M baud rate that should work with the CP2102P in the Slaesh dongle. I also added auto-detection of CP2102 USB/UART adapters in the Python code, so that it can automatically pick the slower baud rate.

I only have the Sonoff dongle (with CC2652P) and not the Slaesh dongle (with CC2652RB), so I'll let you folks test on the Slaesh dongle before I close this.

from sniffle.

Prebuilt firmware binaries for CC2652P/CC1352P and CC2652RB with a 1M baud rate are available with the new v1.9 release so you can test.

from sniffle.