Bug #9715
openRepeater Book Proximity Query, wrong Duplex and Offset information
0%
Description
Not sure if this is a Chirp or Repeater book issue.
If I select Radio->Query Data Source->RepeaterBook->Repeater Book Proximity Query
Location: Melbourne
Distance: 20
Band: 2m (144Mhz)
The return Data for Duplex is (None) and Offset information is blank. This is incorrect. Correct data can be seen from the repeater book web page doing the same query.
Have tried several other countries capital cities and they seem to fail.
Cities in the USA appear to work.
Should this function only work for cities in the USA ?
Cheers
John
Files
| Bad_Duplex_Offset_chirp.png (92 KB) Bad_Duplex_Offset_chirp.png | What Chirp Finds | ||
| Repeater_book.PNG (35.1 KB) Repeater_book.PNG | What Repeater Book Web Page Finds | ||
| RB_CHIRP_Melbourne_2M_25KM.csv (378 Bytes) RB_CHIRP_Melbourne_2M_25KM.csv | |||
| app_direct (858 Bytes) app_direct | .csv file returned from danplanet site |
Updated by J Zuber almost 3 years ago
Updated by Colin Pryke over 2 years ago
I'm observing this behavior too. I think you'll find that the offset data is there (if you export to a .csv then the offset column is correctly populated), but because the duplex field is null (none) then CHiRP is ignoring the offset value even though it's present. Not sure if this used to work as I am a very recent user of CHiRP...
Updated by Jim Unroe over 2 years ago
- File RB_CHIRP_Melbourne_2M_25KM.csv RB_CHIRP_Melbourne_2M_25KM.csv added
- Status changed from New to Feedback
I would suspect that this is a RepeaterBook bug. CHIRP just queries the RepeaterBook API and builds the CSV file or tab based on the data provided. It would seem that the query is not returning the values for the "duplex" fields for Worldwide repeaters but does for North American repeaters.
You might try exporting the list from the RepeaterBook website to a CHIRP compatible CSV file. Exported this way does include the needed "duplex" data (see attached example). Then import the exported CSV file into CHIRP.
Jim KC9HI
Updated by Colin Pryke over 2 years ago
- File app_direct app_direct added
Interesting. If I run Wireshark on my local instance of CHiRP and capture the transaction I can see the RepeaterBook query is actually sent to an app running on the danplanet site via a URI:
http://chirp.danplanet.com/query/rb/1.0/app_direct?loc=Maidenhead&band=14&dist=50
This returns a csv formatted file (attached) with the empty duplex field output. I've been unable to query the repeaterbook API directly via postman so I cannot see if the duplex info is there from the source or not.
Either the danplanet site is running it's own local copy of the RepeaterBook app, or it handles the API transaction with RepeaterBook, but either way this doesn't look like the CHiRP application itself has any problem. I've sent an email to the admin of repeaterbook to make them aware in case this is their issue....
Updated by Colin Pryke over 2 years ago
FIXED! I've been speaking with the repeaterbook admin (Garrett) and they have identified an issue with the repeaterbook output and have fixed it. The duplex value +/- is now output for ALL repeaters - looks like North American repeaters were OK, but repeaters in the rest of the world had this missing from the query. I can confirm that my repeater queries now upload to the radio correctly and operate as expected.
Updated by Masen Furer about 2 years ago
I'm still seeing problems here
http://chirp.danplanet.com/query/rb/1.0/app_direct?loc=98632&band=4&dist=50
These are 70cm repeaters that should all have a standard "+" duplex and 5 MHz offset. But many rows have are showing a "-" duplex.
On repeaterbook, the same query shows that the CSV returned from http://chirp.danplanet.com/query/rb/1.0/app_direct is somehow getting the duplex wrong.