Changes to GPS Slot Times#2

[Rob_Brookes]

Editors Note: Please visit the download section for the latest version of the Callsign Calculator



In order to maintain the required 30 seconds of data silence after a group poll has been sent out from your base, the first GPS radio callsign that can be used is the one with a reply slot time of 30 seconds, that's fairly obvious but with a significant variable having been introduced into the calculation by the FFSK Lead-In Delay value, the position of the GPS radio callsign slides up and down the list of 127 as the Lead-In delay value changes. As such I've designed the spreadsheet so that it will colour all the callsigns with a reply slot time of 30 seconds or more pale green. Thus any callsign from the list with a pale green background can be used for your GPS radios providing you have entered the correct FFSK Lead-In Delay value you are using in your system. The callsigns from 1 to whatever this number is are coloured pale orange and these are available for use with mobile phones or non-GPS assets.

The spreadsheet was designed using MS Excel 2007 where the Conditional Formatting functions have changed significantly from earlier versions. As with most things, 'improvements' make it harder to use. If anyone has problems opening the file which has been saved in the earlier format, or finds they cannot see the necessary cell colour changes, please let me know and I'll produce an Adobe Acrobat .pdf version specifically for your team if you send me the value of FFSK_Lead In Delay you use.
The new version of the spreadsheet is attached to the top of this posting.

As most of you will already know, the point in time when any individual radio sends in its position report is calculated by the radio itself. MRMap only sends out a fire and forget request for a position report, the rest is handled entirely by the radios.

In the past the formula for the calculation used the individual callsign for that radio to produce a unique time slot. All other values were constants held in the radio firmware. Recently this has changed and another variable has been introduced, the FFSK Lead-In Delay. The location of this value in the programming software is shown here.

This is the configuration for an SRM9030 radio intended to be used as an MRMap base receiver.



The calculation for those interested is:-
Response Time (mS) = (( ownDataAddress - baseData Address ) * (350 +> FFSK_LID (mS) ) ) + 320

It's the variable shown as 'FFSK_LID' that has changed from a fixed value previously to the actual value you've entered into the configuration file for your radio.

There is now the potential for teams using the higher callsign values from their block of 127 to have a re-poll period that will mean radios are re-polled before they've actually sent in any position reports. This will cause some radios to disappear from the map and only send in reports when the PTT is released etc. They won't be polled in the normal way.

The MRMap ini file parameter responsible for this is:-

PollRadiosEvery=80

Because of this possibility, I've re jigged the spreadsheet to accept both your team number and the FFSK Lead-in delay you opt to use. The decision you need to make here is that 320 milliseconds is average for systems that don't use repeaters or rebroadcast. And 600ms is about right for teams who do use repeaters etc. From this you can see that the final figure produced by the above calculation can potentially vary quite a bit. Once this 'bit' exceeds the value you have in your ini file for the poll period then those radios may be affected.

The spreadsheet will take your team number and calculate your block of 127 callsigns for MRMap. It will also give you the reply slot time for each callsign and a suggested minimum value for the PollRadiosEvery= parameter in the MRMap ini file. You can use values larger than this but not smaller. The suggested value isn't rocket science, it's two seconds longer than the maximum reply time value calculated for your list of callsigns. That's two seconds longer than the value against radio 127 in the list.
Alongside these changes I've also included cells adjacent to each callsign which you can edit to show the name or description of who has that particular MRMap callsign should you wish to.

The spreadsheet is currently setup for Patterdale MRT using an FFSK_LID value of 250ms. You will need to change both these values to reflect those appropriate to your own team and the spreadsheet should do the rest.

Note that the above currently only applies to data sent at 1200 baud. 2400 baud data does not yet use the modified slot time calculation.

[Rob_Brookes]

Editor Note: Please see the latest version of the callsign calculator - available from the download section.

Apologies to all, please see amendments made to the spreadsheet which is now version xx. Excel has an odd way of handling formula!

[Rob_Brookes]

Well............. We're just not having a good time with this one at all!!

After some testing by Dave and myself which has been duplicated for us by Richard of Cambridgeshire LSAR, we've come to the conclusion that the changes to the slot time calculation in SRP portables affect only the direct polling method where radios are addressed by their individual callsigns rather by using a single group poll as we do. As far as all three of us can tell, the reply slot time for SRP9120 and SRP9130 portables is 320ms regardless of any changes you might make to the FFSK Lead In Delay.

Whether this is the case with the new SRP9170/9180 radios is another matter but if it is then is could explain a lot of things!

The changes to the LID ( FFSK Lead In Delay), that have supposedly occured are reported to not have any detrimental effect on the passage of voice and data through repeaters and LIDs as low as 240 milliseconds are now being suggested as OK for use more or less regardless of whether a repeater is used or not. Such tests as I've been able to carry out using a Team Simoco TSF2025 repeater on the UKSAR mobile repeater channels has backed this up and it would seem to be the case that very low LIDs do work OK.

Thinking about it logically, if you have all your radios waiting to send in their position reports every 340 millisceconds if they have consecutive callsigns then you can't have them do anything that takes longer than this time or you're going to be backing them up in a queue to send off their reports. Indeed, this is what's been happening. Using the LID value of 600ms previously recommended for use with repeaters means each radio will send a dead carrier for 600ms after you release the PTT. If it's also in a queue of radios waiting to send in their position reports every 340ms then something is going to break. The rather obvious solution to this problem (in which it really helps to actually know you have the problem in the first place), is to keep your reply slot times below the magic 340ms. This did seem to resolve timing issues being experienced by some teams using the new SRP9170 portables.

However the original maths used by the radios, to calculate the reply slot time, as already explained, produced a constant value where each radio sent in its position report consecutively after 320ms.

Right....... All of this is very good and my maths tutor would no doubt be proud of me for once but I've now completely lost the plot as to exactly what this new maths is being applied to. Again as far as we can tell at the moment, it works with older, SRP9120 and SRP9130 radios only if you're using individual polling. That is, when you click on a specific radio icon. When MRMap is doing the polling for you, it uses group polling where this new maths doesn't appear to be operating. In the case of the new SRPs, the 9170 and 9180 models, it does seem to be operating when using both methods of polling.

This is very confusing! It means the new SRPs can't be guaranteed to operate in the same way the older models do and this is likely to break the configs for a number of teams.

At the moment until we've sorted it out, I'd suggest you don't change any values in anything unless you appear to have an issue with SRP9170/80s all trying to transmit their position reports at the same time if they've been held off doing this by a normal voice transmission. If this is happening to your radios then reduce your FFSK Lead In Delay to 240ms in the FPP programming.

If you use rebroadcast then it's a completely different matter as LIDs as low as 240ms will prevent the data getting through a rebroadcast device where twice the number of mute gates need to be open at the right moment than are necessary in a repeater.

If you are using rebroadcast then stick with the current recommended values around 600ms for the time being until we can get a definative answer to what's actually been done and to which radios.

Apologies for the confusion surrounding this but it was based on information received which wasn't qualified by saying it only applied to certain methods of polling used by certain models of radio. Myself, Dave and Richard can all confirm that if it is supposed to be working with all models then something has gone wrong because it isn't.

We'll do our best to get this one resolved as soon as possible.

[Rob_Brookes]

Right..........Finally and with a lot of help from Glenn Sneddon, Project Manager at TMC in Australia, we've sorted out what happens with the new maths.

There's also been a small correction to one of the values which was wrong in the original calculation.

In SRP9170 and SRP9180 portables the time at which each consecutively numbered radio replies to a group poll sent to all, is 350ms + the FFSK_Lead In Delay * the number of that radio from its position in the list of 127 for your team.

Or.... 350 + 250 * 1 [2], [3]...[127] etc So with radios having consecutive numeric callsigns, each one will send in it's position report at the appointed time as per the calculation above. As shown here they would be 600ms apart.

The Excel spreadsheet will calculate what the best polling period for MRMap to use with any given FFSK_LID is. The number you enter into the PollRadiosEvery value should not be smaller than the recommended value but it can be larger if you wish.

At the moment this only applies to the radios listed above but I believe the intention is to include the new maths in all models. An important point to note is that you must now have the same value of FFSK_LID in all portables you use and in your base radio. As far as I'm currently aware, the FFSK_LID value in the two radios making up a repeater or rebroadcast unit can be zero. In some makes of repeater, it's not possible to set this value anyway.

I don't know exactly what happens if these values are not the same in all portables and your base but this condition will undoubtedly occur when two teams are working together and where the other team have a different value in ther own radios when compared to the one in your base radio. Maybe we should offer a standardised value in which case it would be to use an FFSK_LID value of 250ms as when added to the internal value of 350ms it gives the 600ms value currently used by a lot of teams and which is the value required by rebroadcast devices in order to get the GPS through the system.

We've received a lot of words of wisdom on the subject of a maximum FFSK_LID value needed to open up the mutes gates of modern repeaters. These values are undoubtedly correct but a lot of teams use rebroadcast and not repeaters. In the case of these devices, a longer Lead-In Delay is needed. A value of 600ms would seem to be optimum and it does no harm whatsoever when the same value is used through a repeater.

However it's important to note that just entering an FFSK_LID value of 600 in the new models will cause it to be added to the internal value of 350ms resulting in a slot reply time for your radios of very nearly one second.

The new maths requires that the total LID is 600ms and so for the time being we are in the slightly awkward position of needing an FFSK_LID value of 250ms in new SRPs but 600ms in older models in order that both models have a reply slot time of 600ms. As soon as this changes I'll let you know.

Maybe you could let me know your experences on this one.

[Rob_Brookes]

Anyone using the newly realeased FPP version 5.58 or any version following on from this one, will now add the new slot time maths to all their radios. This makes life easier where teams use both SRP9120/30 and SRP9170/80 models. The Excel spreadheet somewhere up above this post should now be correct for any radio reprogrammed with FPP 5.58 and above.

At the time of posting this, the minimum reply slot time you can have is 350ms and this is achieved by entering a value of zero into the FFSK Lead-In Delay box. Any value to enter here is added to 350 to produce the final FFSK_LID figure.

Values of LID for repeaters depend on the make of repeater used, some are slower than others in bringing the transmitter up to power. A time of 50ms for this to occur is normally assumed in the event you have access to this information where your own repeaters are concerned.

The timings in the repeater/rebroadcast radios, LID or hang time, have no bearing on this process and can be left as they are if they're working now.

Where rebroadcast is used then a total LID value of 600ms appears to be optimum (enter 250ms into the FFSK LID box) However for teams where the rebroadcast path is multi-hop, where more than one rebroadcast unit is involved, I'm advised that a value of LID around 800ms works better. This is achieved by entering 450ms into the FFSK_LID box.

For ordinary portable to base use with neither repeaters or rebroadcast, the default value of 100ms in the box is fine.

Whichever value you use, it should be the same in all your portable, vehicle and base radios. This is more critical for specific callsign polling than it is for group polling as generally used by MRMap. You only use specific callsign polling when you click on a radio icon otherwise MRMap issues a single, fire and forget, group poll which all radios in the same team will respond to if they hear it.

In the case of specific callsign polling, the number of necessary back and forth transmissions goes up from one to four and this is why we don't use this method on a simplex radio channel, very noisy. However calling an individual radio needs a fairly complex conversation to be held between the polling radio and the one being polled. Whether the conversation is successful depends on the timings between the two radios which must begin from the same basis of both having the same LID value. If these values are significantly different then the conversation goes to pot and the two radios lose effective contact with each other. Same principle as hand-shaking in your old dial up phone modem or getting your SatNav to talk to your computer.

With different values of LID in either your own portable and base radios or between the radios of different teams, you do run the risk of individual radio polling or text messaging coming unstuck but it's not likely to have a huge effect on whether group polling works as this doesn't use hand-shaking. Hence mostly, you won't see any immediate effects even if you ignore it completely. MRMap uses group polling and so doesn't much mind what value of LID you use. Click on a radio icon however and it's a different matter.

Far be it from us (me) to ever suggest what all should use but the current consensus for a 'generic' value of FFSK_LID is between 600ms and 800ms. I'm not convinced that it really matters which value you use between these two numbers but it might. I'll keep an eye on that and test it. This effectively means that you need to enter a value of between 250 and 450ms into the FFSK Lead-In Delay box in the programming software. At the moment two teams in the Lakes have standardised on 800ms total FFSK_LID.