A friend received a 'cease & desist' email from the local DMR network operator, as it was felt his Pi-Star based hotspot was sending extraneous data to the network server, and was told his access would be revoked if he didn't take steps to prevent his hotspot from doing this. Obviously the local DMR network runs on razor thin margins of bandwidth and / or resources.
It got me thinking - what could be done to absolutely minimise the data consumed & generated by our Pi-Stars? This would be useful for people who have low bandwidth connections (eg: weak signal mobile / cell phone connections) and for hams in VK where the DMR network is sensitive to data / resource usage.
A few ideas to this end:
1) I assume hotspots send a network 'beacon' saying to the server "yes, I'm still here, alive & active." Is it possible / appropriate for the user to have control over how often such data is sent to the server? And is there any other extraneous data that could be optionally disabled when necessary?
2) Implement 'quiet hours' where your hotspot is unlikely to be used (eg middle of the night), and have the hotspot hibernate and drop off the network - except for the nightly Pi-Star updates, of course.
3) Also would be nice to implement a programmable input to facilitate a physical external switch so that the user can switch the Pi-Star into 'low data use' mode without logging in to the dashboard interface. Useful for when a hotspot is taken on the go somewhere for portable use via mobile / cell data connection.
Data saver / minimisation for Pi-Star
Re: Data saver / minimisation for Pi-Star
Pistar data is already minimal.
Remember pistar is a 'skin' for MMDVM.
If you want changes like this implemented there might also be a need for them to be actioned by the MMDVM team.
Apart from setting cron tasks / radio prompts (using pistar remote or the API, if its a BM server) to drop connections at specific times or when required, or some other such actions. I'm not sure what can be achieved futhur without writing in extras to MMDVMhost or dmrgateway, which is where the MMDVM team would need to be involved.
I'm also not too sure how limiting data to a dmr server would work. There is an obvious connection from install to server, but afaia You only register with the servers each time ur radio keys up. Obvs. If ur sat all day listening to a tg you are ocuppying bandwidth, in the server pushing traffic out to all those monitoring.
Other than audio /data generated from the radio there's no other 'extenious' traffic, except that which the server 'needs', But. others might show that statement to be incorrect.
Also if your not using the installation 'middle of the night' disconnect from the Tg (tg4000) when closing for the day, shut it down for any prolonged non use. it's that simple really. The user himself must play a responsible part.
Its also a strange idea that anyone would setup a network (or any server application) on a 'razor thin connection' and not strive to ensure it has adequate bandwidth for its user base or use case. I have no idea of bandwidth or the infrastructure of services in ur country, maybe this is the norm? But seems a rather strange ideal to me.
I'm sure the features requested which could be addressed by PS, could /would be if there's enough call for it to be implemented, but.
It would be interesting to ask ur friend to enquire from the server admin what extenious data is being pushed to the server, in this instance.
Sent from my SM-G935F using Tapatalk
Remember pistar is a 'skin' for MMDVM.
If you want changes like this implemented there might also be a need for them to be actioned by the MMDVM team.
Apart from setting cron tasks / radio prompts (using pistar remote or the API, if its a BM server) to drop connections at specific times or when required, or some other such actions. I'm not sure what can be achieved futhur without writing in extras to MMDVMhost or dmrgateway, which is where the MMDVM team would need to be involved.
I'm also not too sure how limiting data to a dmr server would work. There is an obvious connection from install to server, but afaia You only register with the servers each time ur radio keys up. Obvs. If ur sat all day listening to a tg you are ocuppying bandwidth, in the server pushing traffic out to all those monitoring.
Other than audio /data generated from the radio there's no other 'extenious' traffic, except that which the server 'needs', But. others might show that statement to be incorrect.
Also if your not using the installation 'middle of the night' disconnect from the Tg (tg4000) when closing for the day, shut it down for any prolonged non use. it's that simple really. The user himself must play a responsible part.
Its also a strange idea that anyone would setup a network (or any server application) on a 'razor thin connection' and not strive to ensure it has adequate bandwidth for its user base or use case. I have no idea of bandwidth or the infrastructure of services in ur country, maybe this is the norm? But seems a rather strange ideal to me.
I'm sure the features requested which could be addressed by PS, could /would be if there's enough call for it to be implemented, but.
It would be interesting to ask ur friend to enquire from the server admin what extenious data is being pushed to the server, in this instance.
Sent from my SM-G935F using Tapatalk
Andrew M1DNS.
Pi-star Admin Team.
Pi-star Admin Team.