The KiwiSDR 2 online store is open for orders! Please visit kiwisdr.nz

Can't camp using a custom client

Being rural and near SH1 one of the things I do is use my KiwiSDR server to listen in the background to trucks on CB to get an idea of what is happening locally. For this using a web browser is overkill and a resource hog. To get around this I wrote a simple command line client program derived from kiwirecorder. That has worked really well using a fraction of the resources and can be left running 24/7 with minimal impact on my PC.

I want to also be able to listen elsewhere in the house without taking up another receiver slot on the same frequency so that external users can still use my publicly shared KiwiSDR server. For this I wanted to write a camping client which would camp off the receiver servicing my main PC. The problem is the kiwirecorder code base has no concept of camping. I used Wireshark to compare my normal client and the web browser in camping mode and applied the differences I can see but that has not worked.

My first question is if the client-server protocol is documented anywhere? I have been using the source code and Wireshark to reverse engineer it, which is not ideal.

From what I can tell the first HTTP GET needs `?camp` appended to the URI sent but I see minor differences in the first websocket response to my client and the web browser. The more important difference looks to be after the server messages `MSG load_dxcfg` and `MSG cfg_loaded`. With my client I still get the normal `MSG freq_offset=0.000` and `MSG center_freq=15000000` in that packet where as the web browser gets `MSG monitor`. My code looks for the `MSG monitor` as the point to start the flow with `SET GET_USERS` to `MSG user_cb...` and then `SET MON_CAMP=0` to `MSG camp=1,0`.

It would seem to me that adding ?camp to the first GET is not enough to get the KiwiSDR server to treat it as a camping connection. So I kind of have hit a dead end since I can't see any other clear difference.

Comments

  • jksjks
    edited March 20

    Well.. In principle it should work. But I haven't looked at that code in a very long time. And it's a major hack job. So at the very least I'd need some time just to refresh my memory on how it all works.

    But there are 10,000 other things that are higher priority at the moment. Including getting these second build units shipped and other business issues. I can't even seem to get the stuff I'm currently working on into a release. So I can't make any promises when I might look at this..

  • @jks Thanks, relative to other stuff I would agree this is not a priority. I am assuming from your reply there is no client/server documentation for me to browse.

    I will probably dig thru the source code and see what I can work out myself, in between the other projects I am working on.

    Thanks for taking the time to answer :-)

  • Yes, no c/s docs..

Sign In or Register to comment.