I am generating and playing sound over MIDI messages. I need to do some stereo effect (change balance) but I can't find solution.
Now I am trying to use "Chan 1 Control/Mode Change" messages with parameters "08" (first byte) and "0..127" (second byte) but this doesn't work. Can you help me? Thanks.
Your first byte must actually be indicating that you want to send a control change message, and on what channe. Use 0xB0 to send CC on channel 1 before sending the CC number and then value.
Not all devices are going to respond to all CC messages. If you're sending 0x08 and 0x00 - 0x7F and nothing is happening, you probably have such a device.
You might also be trying to change panning instead, which would be 0x0A (10 DEC).
Related
I have bought the wavesharebarcodereader module (https://www.waveshare.com/wiki/Barcode_Scanner_Module) and managed that it decodes codes and sends the data to the rpi. Now i try to use it in command Mode where i can trigger the scanning by sending a byte array.
In my understanding this is an Array of Hexadecimal bytes so i need to suffix each byte with a 0x so i wrote echo "0x7E 0x00 0x08 0x01 0x00 0x02 0x01 0xAB 0xCD" > /dev/serial0 and the voltage of the tx pin drops for a moment as if it would send but the device doesnt react or answer. I also tried without the quotes or single quotes or without the 0x suffix but the device doesnt "understand" it and doesnt react.
Im sure the cabeling is correct and i tested the pins by connecting rx to tx straight and that works too. The barcodereader does work on 3.3V pins too so that is not the problem. I also tried sending the bytes with an arduino but the reader doesnt respond to that either. Sadly all the Documentation on the Reader is this: https://www.waveshare.com/w/upload/d/dd/Barcode_Scanner_Module_Setting_Manual_EN.pdf
Ive been stuck on this problem super long because im very new to uart bytes so any help would be appreciated.
Alright i figured it out:
i needed to use the command: printf "%b" '\x7E\x00\x08\x01\x00\x02\x01\xAB\xCD' > /dev/serial0 and that worked
So I'm converting a Python program I wrote to Erlang, and it's been a long time since I used Erlang. So I guest I'm moved back to beginner level. Anyways from experience every language I use when dealing with sockets have send/recv functions that always return the length of data sent/receive. In Erlangs gen_tcp case however doesn't seem to do that.
So when I call send/recv/or inet:setopts it knows when the packet has ended? Will I need to write a looping recvAll/sendAll function so I can find the escape or \n in the packet(string) I wish to receive?
http://erlang.org/doc/man/gen_tcp.html#recv-2
Example code I'm using:
server(LS) ->
case gen_tcp:accept(LS) of
{ok,S} ->
loop(S),
server(LS);
Other ->
io:format("accept returned ~w - goodbye!~n",[Other]),
ok
end.
loop(S) ->
inet:setopts(S,[{active,once}]),
receive
{tcp,S,Data} ->
Answer = process(Data), % Not implemented in this example
gen_tcp:send(S,Answer),
loop(S);
{tcp_closed,S} ->
io:format("Socket ~w closed [~w]~n",[S,self()]),
ok
end.
Just from looking at examples and documentation it seems like Erlang just knows. And I want to confirm, because the length of data being received can be anywhere between to 20 bytes to 9216 bytes and or could be sent in chunks since the client is a PHP socket library I'm writing.
Thank you,
Ajm.
TL;DR
So when I call send/recv/or inet:setopts it knows when the packet has
ended?
No, it doesn't.
Will I need to write a looping recvAll/sendAll function so I can find
the escape or \n in the packet(string) I wish to receive?
Yes, generally, you will. But erlang can do this job for you.
HOW?
Actually, you couldn't rely on TCP in sense of splitting messages into packets. In general, TCP will split your stream to arbitrary sized chunks, and you program have to assemble this chunks and parse this stream by own. So, first, your protocol must be "self delimiting". For example you can:
In binary protocol - precede each packet with its length (fixed-size field). So, protocol frame will looks like this: <<PacketLength:2/big-unsigned-integer, Packet/binary>>
In text protocol - terminate each line with line feed symbol.
Erlang can help you with this deal. Take a look here http://erlang.org/doc/man/gen_tcp.html#type-option. There is important option:
{packet, PacketType}(TCP/IP sockets)
Defines the type of packets to use for a socket. The following values are valid:
raw | 0
No packaging is done.
1 | 2 | 4
Packets consist of a header specifying the number of bytes in the packet, followed by that number of bytes. The length of header can be one, two, or four bytes; containing an unsigned integer in big-endian byte order. Each send operation will generate the header, and the header will be stripped off on each receive operation.
In current implementation the 4-byte header is limited to 2Gb.
line
Line mode, a packet is a line terminated with newline, lines longer than the receive buffer are truncated.
Last option (line) is most interesting for you. If you'll set this option, erlang will parse input stream internally and yeld packets splitted by lines.
TCP client sends data byte by byte. So, how to tell the server that this message has ended and the new message begins now?
One way is to fix a special character that'll be sent as a bookmark, but that character can also be a part of the message causing confusions.
Any other optimum way out?
If the message is binary, delimited encoding using a special character is not possible. Tag Length Value (TLV) encoding will be best suited for this.
for example
+--------+----------+----------------+
| Tag | Length | Content |
| 0x0001 | 0x000C | "HELLO, WORLD" |
+--------+----------+----------------+
in addition to that, you can have more than one message type
One possible way can be that before sending the actual message you can send the number of bytes in the particular message. When the receiving side has received that number of bytes it can start receiving next message
Checkout the implementation used in networkComms.net, the open source communication framework. In particular IncomingPacketHandleHandOff() on line 892 here.
It guarantees that the first byte received specifies the size of a packet header (Less than 255 bytes). Once enough bytes have been received in order to rebuild the header, the header can be inspected to determine remaining size to be received (data section). If you have more incoming bytes than the expected header and data sections you look at the very first byte and start over.
Using bookmarked characters is what is used at the base level of the network stack but must be implemented carefully to avoid further complications.
If you wish to use a character as both the end of message marker or as a part of the message, you need to use an escape sequence.
For example: Use the character '$' to end the message, and '%' to escape
i.e.
%$ -> $
%% -> %
then use '$' to end the message
All alternatively send the number of bytes to be received at the start of the messssage (or message chunk if you do not know the lenght of the complete message at that point).
This
is the link I learned to send multi-part SMS in PDU, a very good tutorial.But how if I want to send Unicode SMS? From one of the comment from the developer:
Yes, the DCS should be 0×08 and the UDL should be in octets (which ends up being 1 + UDHL + 2 * number of characters). Also you don’t have to insert padding as in the GSM-7 case. I know you’ve already managed to send UCS-2 (not concatenated) messages, so it must be something small you’re missing. If you wish you can post your PDUs so I can check…
Jeroen
it seems I do not need to add 1 bit padding for the message. But if I using the same UDH format as normal SMS it will just show me unknown characters.
Can anyone give me some hints?
This is the sample PDU with chinese character but should be with errors..
0041000B910661345542F60000A00500030302010008044F60597D
Thanks.
Your DCS is wrong.
0041000B910661345542F6000*0*A00500030302010008044F60597D
should be
0041000B910661345542F6000*8*A00500030302010008044F60597D
for a DCS of 0x08 = UCS-2 encoding.
I want to build up an ANT network (e.g. see wikipedia article ) and develop sport accessories using the iPhone 3Gs with integrated ANT Controller (used by Apple for Nike+iPod devices) to communicate with them. I need to know which ANT version the controller is (ANT or ANT+), what it's able to do (receiver/transeiver) and how I can acces the controller with software on iPhone. Until know I was able to access the serial interface and open a socket over WLAN but the only information for this topic was this one. It's one year old before the 3Gs with integrated ANT and External Accessory Framework was released. Changed that something? Are there new efforts of other groups? Every information would be helpful. Thanks.
the apple / nike footpod is not an ANT compatible device. It works with a nordic transceiver nRF2402 but with a different protocol. I reverse engineered it:
The Apple foot pod works with a nRF2402 transmitter and a PIC16F688 microcontroller.
Repetition rate: 1000ms
Number of configuration bytes: 2
Number of address bytes: 2
Number of raw data bytes: 28
Remark: the configuring is sent just before power down, i.e. 2 bytes are transmitted at that time, first 0xe7 then 0x99. The device remains active for approximately 5 seconds after a step has been detected. The device works with a simple piezo sensor to detect footsteps.
A fully transaction is made by sending 3 blocks of 9 bytes, then 11bytes then 10 bytes (almost no gap between each byte within a block, bit clock is below 2us) with a gap of 1.5ms between each block. A crosscheck with the configuration frame of the receiver shows the following:
0x00 0xe0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xc2 0xbd 0x43 0x4f 0x33
This means (see datasheet of nRF2401; configuration):
- channel 0x19 -> 2425MHz
- RF power max; 16MHz clk; shock burst; 250kbps; 1 RX channel active
- CRC enabled; CRC 16bit; address length 16bit
- Address for channel 1: 0xc2bd (high byte first)
- Address for channel 2: all 0x00
- 0xe0 -> 224 data bits for channel 1
- 0x00 -> 0 data bits for channel 2
The address length is 16 bit, and 224 bits of raw data are transmitted. The standard device address is 0xc2 0xbd anyway the data sent via link starts with the following pattern:
Address: 0xC2 1. byte of block 1
0xBD 2. byte of block 1
Data: 0x0D 3. byte of block 1
0x01 4. byte of block 1
0x47 5. byte of block 1
0xA0 6. byte of block 1
0x54 7. byte of block 1
0x22 8. byte of block 1
0xA0 9. byte of block 1
. 10.byte of block 2
. 11.byte of block 2
.
hope this helps a little
What makes you sure the iPhone (3GS) uses a nordic transceiver? It seems not visible to me on the tear down at ifixit. We assumed the BCM4325 is used for the "ANT" communication as well.
by the way, the ANT and ANT+ protocol works with full speed 1MBit/sec instead of the lower footpod speed of 250kBit/sec. The length of a frame in the nike footpod is also different compared to the ANT protocol. From a HW point of view, it is possible to run an ANT or even ANT+ protocol on an i-phone without any external HW! The transceiver is already integrated. If one had access to the nRF2401 transceiver within the i-phone writing an ANT protocol handler is a piece of cake, the ANT protocol is a pretty stupid thing and easy to implement! The ANT+ is encrypted with an 8 byte key. I guess they use the safer algorithm but I'm not sure. See also: SAFER (Secure And Fast Encryption Routine) is the name of a family of block ciphers designed primarily by James Massey on wikipedia (source code downloadable at ETH in zürich or just ask me... good luck