동료가 개발 한 GNU Radio 애플리케이션 용 웹 프런트 엔드를 개발 중입니다.GnuRadio tcp_sink 데이터 값이 왜곡됩니다.
두 개의 TCP Sink 블록의 출력에 연결되는 TCP 클라이언트가 있는데 데이터 인코딩이 예상대로되지 않습니다.
하나의 TCP Sink은 복잡한 데이터를 보내고 다른 하나는 플로트 데이터를 보냅니다.
각 4 바이트 청크를 float32 값으로 읽음으로써 클라이언트에서 데이터를 디코딩하고 있습니다. 서버와 클라이언트는 둘 다 little-endian 시스템이지만 바이트 스왑 (GNU Radio Endian Swap 블록을 사용하고 클라이언트에서도 수동으로 시도)을 시도했지만 데이터가 여전히 올바르지 않습니다. 실제로 그것은 훨씬 나빠서 바이트 순서 불일치가 없음을 확인합니다.
적절한 GUI 요소를 사용하여 GNU Radio Companion에서 플로우 그래프를 실행할 때 플롯이 올바르게 보입니다. 데이터 값은 0에서 10 사이에 예상대로 표시됩니다.
그러나 클라이언트에서 디코딩 된 값은 일반적으로 약 0.00xxxxx이며, 음모는 GNU Radio에서와 같이 간단한 톤을 나타내는 것이 아니라 잡음처럼 보입니다. 1000 배로 수동으로 데이터 크기를 조정하면 여전히 노이즈처럼 보입니다.
이 짧은 이후 나는 GNU 라디오에서 전 D 경로를 설명 할 것이다,하지만 난 다음 A A Throttle 블록과 다음에 WBFM Receive과 Rational Resampler가 추가 된 후 D 경로에 같은 문제를 참조하십시오 TCP Sink 블록 전송 플로트 데이터.
File Source (Output Type: complex, vector length: 1) =>
Throttle (vector length: 1) =>
Low Pass Filter (FIR Type: Complex->Complex (Decimating)) =>
Throttle (vector length: 1) =>
TCP Sink (input type: complex, vector length: 1).
이 스트림 매개 변수 (내가 스트림 항목 불일치 변경하면 실제로 동반자가 오류를 표시)를 지정하는 올바른 방법이 될 것 같다,하지만 난 다른 한편으로 정확하게 데이터를 디코딩 할 수있는 방법을 찾을 수 있습니다 스트림의 끝.
왜 '스로틀 (throttle)'블록을 사용하고 있으며 그 중 왜 두 개까지 사용 했습니까? 스로틀은 당신의 신호에 정확히 아무런 영향을 미치지 않습니다. 처리 속도가 느려집니다. 동일한 샘플 경로에 두 개의 샘플을 두어서는 안됩니다. –
그래서 나쁜 소식입니다. 먼저 GNU Radio가 3.8 릴리스를 준비 중이며 TCP 싱크가 더 이상 사용되지 않아 제거 될 것입니다. 따라서 여러분은 그것들을 전혀 피할 수도 있습니다. 특히 많은 방법들에서 꽤 끔찍한 것이기 때문에 (나는 토론하는 방법을 설명 할 수 있습니다 - gnuradio 메일 링리스트). –
하지만 이것이 문제라고 생각하지 않습니다. 데시 메이션 팩터는 무엇입니까? –