Problem with audio capture on ALC5645 headphone microphone - codec

Has anyone seen (fixed?) a problem with strings of zeroes in audio data captured with the AL5645 codec microphone input on the Coral dev board? It's happening for me with default settings using arecord, as well as my python code using PyAudio. 16 bit (mono) samples, sample rates 16000Hz and 44100Hz. e.g. 83 ce 34 0b 09 3f 00 00 00 00 00 00 2b 0e 2b 0e b0 d0 5a b9 ee d9 00 00 00 00 75 44 75 44 75 44 ba 38 8a ff e6 c6 00 00 00 00 00 e7 00 e7 00 e7 85 26 f4 46 bc 2e
?
Cheers,
Mark

Related

SYN ACK not getting received

I am implementing a server and have an issue with the handshaking. When I get the arp request the response is given ok, then I get the SYN. I respond to the SYN with a SYN ACK but I don't get an ACK back.
The sequence numbers and ack's seem to be in order as well as the id's, the checksums add up aswell to. Any ideas why the SYN ACK is not getting recieved?
Arp Request:
0000 ff ff ff ff ff ff e0 3f 49 b7 8e 39 08 06 00 01
0010 08 00 06 04 00 01 e0 3f 49 b7 8e 39 c0 a8 00 01
0020 00 00 00 00 00 00 c0 a8 00 0c
Arp reply:
0000 ff ff ff ff ff ff 00 14 a5 76 19 3f 08 06 00 01
0010 08 00 06 04 00 02 00 14 a5 76 19 3f c0 a8 00 0c
0020 e0 3f 49 b7 8e 39 e0 3f 49 b7 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00
SYN:
0000 00 14 a5 76 19 3f e0 3f 49 b7 8e 39 08 00 45 00
0010 00 34 1e d2 40 00 80 06 5a 94 c0 a8 00 01 c0 a8
0020 00 0c 13 79 00 50 95 01 61 8e 00 00 00 00 80 02
0030 20 00 c3 59 00 00 02 04 05 b4 01 03 03 08 01 01
0040 04 02
SYN ACK:
0000 e0 3f 49 b7 8e 39 00 14 a5 76 19 3f 08 00 45 00
0010 00 2c 1e d2 40 00 80 06 5a 9c c0 a8 00 0c c0 a8
0020 00 01 00 50 13 79 d6 a2 5f 1b 95 01 61 8f 60 12
0030 05 ee d0 e6 00 00 02 04 05 78 00 00

Dota2 packet analysis uknown wiretype for proto message

I am trying to gain access to in game chat information from dota2 packets. I knew this used to possible since there were multiple projects that intercepted dota2 network traffic and translated chat text to print out on an overlay over dota2. Right now I am using wireshark with protobuf addon installed. I can see a few packets here and there to valve servers outside the USA and can see the protobuf addon for wireshark working on these packets but I get an unknown wiretype error for 95% of the packets I believe to be related to dota. In almost all of these packets the UDP data payload starts off with 56 53 30 31
here is an example hex dump from wireshark. Are these 4 bytes some sort of header and then the proto messages start?
0000 c8 a7 0a a4 63 ed 6c fd b9 4b 6e 16 08 00 45 00
0010 00 70 58 db 40 00 40 11 85 1a c0 a8 01 f5 d0 40
0020 c9 a9 9e 96 69 89 00 5c 72 7c **56 53 30 31** 30 00
0030 06 00 00 02 00 00 00 1d fe 11 11 10 00 00 d7 0a
0040 00 00 01 00 00 00 11 10 00 00 30 00 00 00 24 fd
0050 37 3c b4 30 a5 48 fa 3d ea 30 1a 1f d8 a9 41 e0
0060 e0 6c 44 ba bb 4e ba fc e7 ac ed f9 40 19 86 20
0070 84 71 52 5d b3 1f da 36 40 d9 b6 2e e1 e5
That is ascii code for "VS01", so yes, it might be some kind of version identifier.

Float to hex conversion - reverse engineering

I'm trying to do some reverse engineering on my heating system. Monitoring the CAN BUS results in receiving hexademical strings, for example:
00 D0 68 D6 86 83 61 8F
61 C0 02 5C 12 B5 02 5C
12 78 04 39 04 03 05 02
05 C4 04 5C 12 5C 12 5C
12 5C 12 D0 68 00 00 00
00 18 08 37 D2 00 00 00
00 00 00 00 00 15 75 F2
F0 01 00 01 00 00 00 1F
I know that for example the temperature value of 22.5°C should be somewhere in there.
So far I have tried to look for the following conversions:
Possibility 1: ascii to hex
22.5 = 32 32 2E 35
Possibility 2: float to hex conversion
22.5 = 0x 41 b4 00 00
However none of these resulted in a match.
What would be other possibilities to converted a float to a hex string?
Thx
note: the given string is just a small part of my can sniffer so don't look for 22.5 in my given string here. I'm just looking for other possible conversions.

Date and time from hex

I'm trying to read public transport cards and I've figured out the data format mostly but the record dates and times are a mystery. Some data:
e1 a2 00 00 ce 04 05 b1 7e 00 68 22 0a 10 00 ce - 01.03.2014 23:36
e4 a2 00 00 ce 04 e5 7b 7e 00 e4 2e 0a 10 00 e9 - 04.03.2014 16:31
e4 a2 00 00 4c 04 43 8c d0 07 30 00 01 00 00 72 - 04.03.2014 18:42
e4 a2 00 00 ce 04 65 8d 7e 00 7c 17 0a 10 00 a2 - 04.03.2014 18:51
ea a2 00 00 ce 04 25 63 7e 00 70 09 0a 10 00 f1 - 10.03.2014 13:13
ec a2 00 00 ce 04 25 63 7e 00 70 09 0a 10 00 da - 12.03.2014 13:13
f3 a2 00 00 ce 04 85 69 7e 00 64 3b 0a 10 00 9d - 19.03.2014 14:04
f5 a2 00 00 ce 04 e5 89 7e 00 70 22 0a 10 00 ba - 21.03.2014 18:23
f6 a2 00 00 ce 04 6a 00 82 01 68 22 2a 10 00 df - 22.03.2014 00:03
fb a2 00 00 ce 04 85 75 7e 00 84 17 0a 10 00 2a - 27.03.2014 15:40
fb a2 00 00 ce 04 a5 91 7e 00 78 17 0a 10 00 a6 - 27.03.2014 19:25
c1 a2 28 00 ce 04 0b 6b 00 00 74 17 08 10 04 94 - 28.01.2014 14:16
c7 a2 00 00 ce 04 a5 5d 7e 00 6c 09 0a 10 00 1b - 03.02.2014 12:29
c7 a2 00 00 ce 04 25 6c 7e 00 68 2d 0a 10 00 68 - 03.02.2014 14:25
c7 a2 0e 00 ce 04 eb 6d 00 00 88 17 08 10 04 45 - 03.02.2014 14:39
ce a2 00 00 ce 04 85 52 7e 00 68 09 0a 10 00 77 - 10.02.2014 11:00
ce a2 00 00 ce 04 e5 5c 7e 00 64 09 0a 10 00 58 - 10.02.2014 12:23
eb a2 00 00 ce 04 85 41 7e 00 80 22 0a 10 00 dd - 11.03.2014 08:44
eb a2 00 00 ce 04 85 6a 7e 00 a4 28 0a 10 00 66 - 11.03.2014 14:12
eb a2 20 00 ce 04 8b 6e 00 00 7c 17 08 10 04 e0 - 11.03.2014 14:44
|| || || || ** ** ** ** **
Date? Time?
Stars represent known data (as in I know what those mean and they aren't relevant to date and time)
Provided dates are correct, because they're from usage history printout.
I've tried converting values to unix timestamps, seconds, milliseconds and much more, but I can't determine the format. Also the data might be in little endian.
I'm not sure about possible timezone, data might be in UTC, UTC+2 or UTC+3.
I appreciate any help.
I figured out the format, it goes like this:
All data is in little endian.
To get the time in minutes, the value must be bitsifted to right five times.
For example:
6e8b >> 5 = 884
884 minutes = 14 hours, 44 minutes (14:44)
Date is days from 1.1.1900. For example:
a2eb = 41707 (11.03.2014)

Writing a Driver for an Extech HD300 Anemometer

I started a thread in the NI support forums about my project, but my current problem is more broad than just driver writing in labview. I have an anemometer that uses a USB UART bridge
to interface with the computer. I asked Extech for any kind of documentation for and received only the communication protocol below.
Serial Communication Protocol
I encountered several problems working with this, so I took the software included with the anemometer and used portmon to sniff the commands going to and from, and here's where it gets worse. To simplify matters as best as I could, I only took ambient temperature readings. The following was what portmon captured when I used the manufacture's software to connect to the instument:
(This is the 'upload protocol' on the above protocol documentation)
AA 61 64 6A 67 08 40 00 40 00 01 00 00 C6 41 00 00 00 00 00 3C 1C C6 9A 19 99 42 00 3C 1C C6 00 00
AA 61 64 6A 67 08 40 10 40 00 01 7D 0C C6 41 00 00 00 00 00 3C 1C C6 39 1F 99 42 00 3C 1C C6 00 00
AA 61 64 6A 67 08 40 10 40 00 01 00 00 C6 41 00 00 00 00 00 3C 1C C6 9A 19 99 42 00 3C 1C C6 00 00
AA 61 64 6A 67 08 40 10 40 00 01 83 F3 C5 41 00 00 00 00 00 3C 1C C6 FB 13 99 42 00 3C 1C C6 00 00
This is slightly truncated, but the important parts should be there. The ambient temperature read about 76.5F at the time. So according to the documentation, this should be in the 10-13th bits, so I believe:
0000c641
7d0cc641
0000c641
83f3c541
To be the recorded ambient temperatures, but I have no idea how to read this. I see no reason why a conversion from Kelvin or Celsius would be necessary as there seems to be a bit for that in F1. Also of note is the fact that I get values completely different than anything documented for several fields, so either I'm reading something wrong or the documentation is just wrong. I haven't been able to get any more answers from the manufacturer about the protocol, so I have no idea why my data only half resembles what is expected.
41C60000 converts to 24.75 as an IEEE754 standard 32-bit single precision float. This looks like a Celsius value which would map to 76.55 F.
For the rest of the data you would have :
41C60000 = 24.7500000000000000000
41C60C7D = 24.7560977935791015625
41C5F383 = 24.7439022064208984375
I think that sorts out the endianness and formatting for you.

Resources