2016-10-26 10 views
1

LoRaデバイスAからデータを送信する際に、小さな問題に直面しています。 という16進文字列をStringまたはchar文字列として送信しています今まで同じ結果が得られているものの)Nodejsの同じbase64文字列をデコードすると、異なる結果が発生する

String packet = "025555AD4148E1BE4100A06E421954C5BB"; 
//char data[] = "025555AD4148E1BE4100A06E421954C5BB"; 

しかし、バックエンドで受け取った場合、文字列はbase64のようになります。

異なるデバイス(LORA B)に受信されたbase64文字列から、実際には異なる
msg.payload = MDJhYmFhNmE0MTUyYjhjNDQxMDBjNDgwNDIwMDAwMDcwOQ== 

、送信されたペイロードは、同じであっても、この第二の装置(LORA B装置)は、このmsg.payload = AquqakFSuMRBAMSAQgAABwk=

場合を受け取ります私は

var b = new Buffer(msg.payload,'base64') 

が、私は私の16進数の文字列でない文字の次束を得ると同じ機能をnodejsにLORAとLORA B base64でデコード

30326162616136613431353262386334343130306334383034323030303030373039 < = LORA A 02ABAA6A4152B8C44100C4804200000709 < = LORA B

それでは、私が思うことは、ここで何が起こっている元進数文字列が 文字に分割し、LORAを介して送信されていることです。したがって、私が得るものは、 の16進数のASCII表現です。そうですか?

次に、元の16進文字列を取得するにはどうすればよいですか?

ありがとうございます。

よろしく!

EDIT:私の推測が示唆されたとして、問題はペイロードが

payload = 'MDJhYmFhNmE0MTUyYjhjNDQxMDBjNDgwNDIwMDAwMDcwOQ=='; 

b = new Buffer(payload,'base64') 
console.log("Buffer b raw "); 
console.log(b); 
console.log("Buffer b stringfied "); 
console.log(b.toString()); 

戻り送信される前ではなくbase64でエンコード/デコード中のプロセスである道上にあるように思わ

Buffer b raw 
<Buffer 30 32 61 62 61 61 36 61 34 31 35 32 62 38 63 34 34 31 30 30 63 34 38 30 34 32 30 30 30 30 30 37 30 39> 
Buffer b stringfied 
02abaa6a4152b8c44100c4804200000709 

macTransmitを見ると、デバイス内のcode that is being used to transmitの機能では、HEXの文字に

for (int i = 0; i < size; ++i) { 
    this->loraStream->print(static_cast<char>(NIBBLE_TO_HEX_CHAR(HIGH_NIBBLE(payload[i])))); 
    this->loraStream->print(static_cast<char>(NIBBLE_TO_HEX_CHAR(LOW_NIBBLE(payload[i]))));} 
+0

したがって、 '025555AD4148E1BE4100A06E421954C5BB'をbase64に変換するにはどうすればよいですか? – zerkms

+0

これはLoRaWANスタック自体によって行われ、私のコントロール外です。デバイスに16進数の文字列を入力するだけです。私が見ているのは、LoRa Aのデコードされたデータは、LoRa Bのデータのアスキーの表現であるということです。B – ndarkness

+0

データのエンコード方法や入力フォーマットを調べてください。 – zerkms

答えて

1

あなたLORAクライアントライブラリは、あなたがそれを送信するためにバイトの配列ではなく、進数の文字列を与えることを期待しています。バイト< 025555AD4148E1BE4100A06E421954C5BBを送信するために

>、あなたのように自分のパケットを初期化する必要があります:あなたはOPで行ったようにあなたは、文字列を送信すると

char packet[] = {0x02, 0x55, 0x55, 0xAD, 0x41, 0x48, 0xE1, 0xBE, 0x41, 0x00, 0xA0, 0x6E, 0x42, 0x19, 0x54, 0xC5, 0xBB};

、それはあまりにも、バイトの配列です。しかし、各バイトはASCIIコードの16進数(2桁の16進数は1バイトを構成します)です。

あなたはASCII文字

char data[] = "025555AD4148E1BE4100A06E421954C5BB";

<30>は、文字のASCIIエンコーディングがあるので、それは<30>を開始するバイトとしてのこの文字列を見れば「0」。それは<32>となります。これは、ASCII文字 '2'のエンコードであるためです。そのため、data[0]の1バイトの<02>ではなく、メッセージが2バイトの<30 32>で始まります。これはどこにあるのか分かりますか?長いバッファー<Buffer 30 32 61 62 61 61 36 61 34 31 35 32 62 38 63 34 34 31 30 30 63 34 38 30 34 32 30 30 30 30 30 37 30 39>は、送信したメッセージのASCII表現とまったく同じです( "025555AD4148E1BE4100A06E421954C5BB")。これにより、base64変換に何も問題がないことが確認されます。

ループが表示されるループは、ライブラリがバイトを予期していることを確認します。パケットの各バイトを2つのニブルに分割し、各ニブル(16進数)を対応するASCII文字(0-F)に変換しています。 Microchip RN2483 LoRaモジュールは、シリアルスタイルのプロトコルを介してホストコントローラと通信するように設計されているため、パケットをテキスト文字として送信します。内部的には、送信前にテキストバージョンのパケットをバイトに戻します。

関連する問題