Hi Keith,
On Fri, Feb 24, 2017 at 7:42 AM, Keith keith@rhizomatica.org wrote:
Hi Alexander, seeing as how you came in on the thread, as a side topic, you may have noticed I mentioned meas_json and meas_web in the OP. I fixed up a small thing with meas_json that was producing unparseable json in the neighbours array.
Thank you. Please submit a patch when main meas_json lands into the master.
It looks like the patch was lost during the patchworks->Gerrit transition, so I re-submitted it to Gerrit here: https://gerrit.osmocom.org/#/c/1915/
I also did some stuff server side to filter for either SDCCH or TCH, although I think I would make this a clientside javascript filter option, rather than running multiple websocketd
Yes, this should rather be client side I believe.
I added the neighbour levels to the displayed data. I hardcoded the ARFCNs for the site in question, but I would make that happen dynamically. I found this quite useful for monitoring in relation to analysis on this site and the would-be handover scenario.
Sounds very useful indeed! And yes, ARFCN clearly should be dynamic before such a change oculd be merged. But this doesn't mean you should not commit your change in a WIP branch - commit early, commit often. :)
I'm wondering what to do with this work.
I'm glad the code is useful and happy to review your changes.
Should I make a commit of meas_json to master? In that case I would appreciate some minor help getting the Makefile right.
If the commit is ready in general - please submit it to Gerrit and add me as a reviewer.
Maybe meas_json is not a candidate for the master branch, as it doesn't currently do anything particularly useful without the external dependencies, ie meas_web and websocketd or alternative.
Well, it's a kind of an external API, so it's as useful as any other API.
I can publish my work on meas_web to github.
That would be great. Please submit a pull request when you feel ready.