On 06/01/2016 18:20, Michael Black wrote:
Looking for feedback on this changed patch. Had to make the
QNetAccessManager a little more accessible since it was only in main.
I'm obviously not as good at Qt as you are...so hopefully this is better.
I chatted a bit on the IRC channel for the balloon people and they
thought the grid-change idea should work.
I also have contacted r...@habhub.org <mailto:r...@habhub.org> to get
feedback too. Who is Mal?
They did say any unregistered call would not get reported so there
would be little-to-no load on the SNUS server for this since grid
changes never occur (as of yet that I've ever seen).
So only balloon payloads should cause WSJT-X to report. If rovers
start using JT modes that might change in the future but I've not seen
any yet. Even then that would be low traffic.
RRR
Mike W9MDB
Hi Mike,
lots of issues with your proposed patch.
First of all it is trying to send spots from fast modes like JT9E/F/H,
JTMSK and, ISCAT. If we want to send from HF JT9 and WSPR spots it need
to go somewhere else in the code.
For the actual POST to the server you must be careful when using a
shared QNetworkAccessManager since it is handling other requests in
parallel. Your finished slot will grab all request completions and
destroy them, that is very bad! You can use code like this to be selective:
// send telemetry to HAB server if required
// will send the RX station callsign, grid, frequency and JT9/65
string
decodedtext.deCallAndGrid(/*out*/dx_call,dx_grid);
if (decodedtext.isJT9 ()
&& m_config.spot_to_snus_reporter ()
&& stdMsg
&& !m_diskData) {
QString dx_call;
QString dx_grid;
if (gridChanged(dx_call,dx_grid)) {
Frequency frequency = m_dialFreq + decodedtext.frequencyOffset();
QUrlQuery q;
q.addQueryItem("callsign", m_config.my_callsign());
q.addQueryItem("grid", m_config.my_grid());
q.addQueryItem("frequency", QString::number(frequency));
q.addQueryItem("data", decodedtext.string().replace("+", "%2B"));
q.addQueryItem("version", version());
auto request = QNetworkRequest
{{"http://vps.comms.net.au/snus.php"}};
request.setHeader (QNetworRequest::ContentTypeHeader,
"application/x-www-form-urlencoded");
auto * reply = m_network_manager->post (request,
post_data.toString (QUrl::FullyEncoded).toUtf8 ());
connect (reply, &QNetworkReply::finished, [this, reply] () {
if (reply->error ()) {
QMessageBox::warning (this, tr ("Network Error"),
tr ("failed to send spot to SNUS
server:\n%1\n%2")
.arg (reply->url
().toDisplayString ())
.arg (reply->errorString ());
);
reply->deleteLater ();
});
}
}
}
Note:
1) the correctly formed POST request with a content type header,
2) the connect which is only on the specific reply rather than on all
QNAM:finished() signals,
3) the lambda function is much neater when dealing with simple actions
on a signal,
4) the two part check up front so that we don't waste time and space
string and checking other mode grids.
The above code would be needed in yet another different place for WSPR
decodes and the way that call, grid and frequency is extracted there is
different but fortunately fairly easy due to there only being two
variants of WSPR decode.
Looking at the source code posted on their web page it only seems to
post JT9 spots. We need to speak to them and get a definitive answer to
what modes and bands need spotting of potential balloon vehicles.
I am slightly concerned about the moving grid algorithm since it will
never post the first spot. For marginal copy that may be a loss of
valuable data. Having them publish their registered vehicles as a JSON
file with a GET request from their web service should be easy for them
if they are filtering themselves.
We need a way of doing a test either to a test service URL or perhaps
with a test callsign.
Mal is the OP of this thread VK6MT.
73
Bill
G4WJS.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
