2016-10-26 7 views
1

LoRa 장치 A를 통해 데이터를 보내는 동안 작은 문제가 발생합니다. 16 진수 문자열을 String 또는 char 문자열로 보내고 있습니다. 그러나 지금까지와 같은 결과를 가지고있는 것들)Nodejs에서 동일한 base64 문자열을 디코딩하면 다른 결과가 발생합니다.

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

그럼에도 불구하고 백엔드에서받은 문자열은 base64에서 다음과 같이 보입니다.

다른 기기 (로라 B)에 수신되는베이스 64 열로부터 실제로 다른
msg.payload = MDJhYmFhNmE0MTUyYjhjNDQxMDBjNDgwNDIwMDAwMDcwOQ== 

, 전송 된 페이로드가 동일하더라도, 두 번째 장치 (로라 B 장치)이 msg.payload = AquqakFSuMRBAMSAQgAABwk=

경우 수신 나는

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

내가 내 16 진수 문자열하지 않은 문자의 다음과 같은 무리를 얻을 같은 기능을 nodejs에서 로라와 로라 B base64로 디코딩

30326162616136613431353262386334343130306334383034323030303030373039 < = 로라 02ABAA6A4152B8C44100C4804200000709 < = 로라 B

그래서 내가 여기에 무슨 일이 일어나고 생각하는 것은 원래의 진수 문자열입니다 가 문자로 분할하고 로라를 통해 전송되는 것입니다. 따라서 내가 얻는 것은 ASCII 표현의 16 진수입니다. 맞습니까?

다음 질문은 어떻게 원래의 16 진수 문자열을 얻을 수 있습니까?

미리 감사드립니다.

감사합니다!

편집 : 내 추측이 제안되면서, 문제가 페이로드

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로 799,458,114,403,210는

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의 데이터 ascii로 표현된다는 것입니다. B – ndarkness

+0

데이터 인코딩 방법 및/또는 예상되는 입력 형식에 대한 문서를 확인하십시오. – zerkms

답변

1

귀하의 로라 클라이언트 라이브러리는 당신이 그것을 보낼 바이트의 배열, 16 진수 아닌 문자열을 줄 것으로 기대가 문자.

가 바이트 < 025555AD4148E1BE4100A06E421954C5BB>를 전송하려면로 패킷을 초기화해야합니다

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

당신이 영업 이익에 그랬던 것처럼, 그 역시 바이트의 배열의 문자열을 보낼 때. 그러나 각 바이트는 16 진수 (두 자리 16 진수는 1 바이트를 구성)의 ASCII 인코딩입니다.

당신이 ASCII 문자

char data[] = "025555AD4148E1BE4100A06E421954C5BB";

<30>은 문자의 ASCII 인코딩이기 때문에, 그것은 <30>로 시작하는 것 바이트로이 캐릭터 라인을 보면 '0'. 그러면 ASCII 문자 '2'의 인코딩이기 때문에 <32>이 올 것입니다. 따라서 위치 data[0]에있는 단일 바이트 <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> 정확히 "025555AD4148E1BE4100A06E421954C5BB"보낸 메시지의 ASCII 표현입니다. 이것은 base64 변환에 문제가 없음을 확인합니다.

표시된 루프 for은 라이브러리가 바이트를 필요로하는지 확인합니다. 패킷의 각 바이트를 가져 와서 두 개의 니블로 나누고 각 니블 (16 진수)을 해당 ASCII 문자 (0-F)로 변환합니다. Microchip RN2483 LoRa 모듈은 직렬 스타일 프로토콜을 통해 호스트 컨트롤러와 통신하도록 설계 되었기 때문에 패킷을 텍스트 문자로 전송합니다. 내부적으로는 전송하기 전에 텍스트 버전의 패킷을 다시 바이트로 변환합니다.