For Piso WiFi operators: Fair bandwidth limits should be derived from real WAN capacity and peak concurrent users. A per-user limit that looks generous with two users can overload the backhaul when twenty users arrive.
Start with the correct platform and role
Piso WiFi is a category of prepaid/captive-portal deployments, not one standardized router firmware. A vending/controller platform, the upstream ISP router, and separate Wi-Fi access points can all have different addresses and credentials. The customer portal and the operator admin page are also different security roles. Controller and router queue features differ; treat platform limits and upstream-router QoS as separate layers.
Step-by-step checklist
- Measure stable wired WAN download, upload and loaded latency.
- Reserve capacity for DNS, portal/payment services and overhead.
- Choose a realistic per-user floor/ceiling based on expected concurrency.
- Prioritize low-latency fairness over one user consuming the full backhaul.
- Test video call/browsing while several controlled downloads/uploads run.
- Revisit limits at actual peak hours and after changing ISP plans.
What not to assume?
Do not set total customer limits whose sum can massively exceed the WAN and then expect QoS to create bandwidth. Upload congestion is especially damaging to latency. Likewise, 10.0.0.1 is only a private IPv4 address. Its presence does not identify the software by itself, and changing the address does not change how the vending/session system works.
Customer-side checks
- Stay connected to the Piso WiFi SSID and turn off a VPN temporarily if the portal will not open.
- Do not type operator credentials into a public search result.
- If a portal fails only on one phone, test browser captive-portal state, Private DNS, MAC randomization and date/time before blaming the machine.
- Keep payment/voucher proof until the session is confirmed.
- For pause/resume or voucher issues, use the same device when the platform ties sessions to a device identity.
Operator-side checks
Troubleshoot in layers. Confirm stable power, then WAN internet, controller WAN/LAN interfaces, DHCP/DNS, access-point reachability, captive-portal service, payment input, and finally the user/session database. If every client fails, focus on shared infrastructure. If one client fails, compare that client with a working one before rebooting or resetting the system.
Security and reliability
- Change initial/factory administrator credentials after setup.
- Keep customer traffic separated from the management LAN where the platform supports it.
- Use official software updates and make backups before upgrading.
- Protect the controller, coin acceptor and power hardware from moisture, heat and unstable power.
- Use a proper access point for coverage and capacity rather than assuming the controller board’s radio can serve a busy area.
- Never expose the admin dashboard directly to the public internet through an unrestricted port forward.
Network architecture matters more than the portal IP
A healthy installation normally has a clear upstream/downstream design: ISP modem or ONT, then the device responsible for routing/session control, then switches/access points serving customers. Avoid accidental double DHCP, overlapping subnets and a consumer Wi-Fi router running NAT behind the vending controller unless the design intentionally calls for another routed boundary. Label WAN and LAN cables so a maintenance visit does not silently reverse them.
Payment and session integrity
When money or vouchers are involved, troubleshoot payment confirmation separately from internet access. Keep transaction/session logs long enough for legitimate support and reconciliation, but do not collect secrets that the payment provider does not require. For digital wallets, the operator should never request a customer PIN or one-time password. Test duplicate payments, failed callbacks, controller restarts and recovery after power loss before advertising a new payment option.
Maintenance checklist
- Keep the controller/router and access-point software on supported releases from the official vendor.
- Back up configuration before updates and store a copy away from the machine.
- Check power supply, ventilation, storage health and cable condition.
- Review peak-hour WAN utilization, loaded latency and access-point client counts.
- Audit admin accounts after staff/vendor changes and remove access that is no longer needed.
- Test the customer journey—from joining Wi-Fi through payment, portal access, session expiry and reconnect—after every major change.
Check the exact platform before using credentials or reset steps
Piso WiFi systems are not one standardized firmware. Match the machine name, installed version, controller type and local network before applying a login, password-recovery or reset instruction. If the device label or installed platform shows a different address or workflow, use the information for that exact machine rather than forcing a value from another platform.
Use measured capacity, not the ISP package headline
Measure download, upload, and loaded latency over Ethernet during several periods, especially the hours when the hotspot is busy. Reserve capacity for portal/payment traffic, DNS, and normal protocol overhead. Then choose a realistic customer ceiling. If the uplink is 20 Mbps and twenty users are active, a 10 Mbps limit per device does not create 200 Mbps of real capacity; it only defines the maximum each user may request.
Per-user versus global shaping
AdoPiSoft currently supports per-captive-portal-user upload/download limits and an optional global bandwidth limit shared by all users. A global ceiling can protect the upstream link, while per-user shaping prevents one client from dominating it. The right balance depends on concurrency and application mix. Upload saturation is especially damaging because full upstream queues can make DNS, browsing, payments, and voice calls feel slow even when download tests look acceptable.
Measure fairness at peak load
Test more than raw throughput. Run a video call or interactive browsing session while controlled downloads and uploads are active. Watch latency and packet loss, not just Mbps. If one access point has many clients while another is idle, the bottleneck may be radio airtime rather than WAN bandwidth; adding more speed limits will not fix poor channel planning or weak backhaul.
Build limits around applications, not only speed-test numbers
Interactive browsing, messaging, voice calls, software updates, short-form video, and large cloud uploads stress the connection differently. A fair plan needs enough per-user throughput for normal pages and media while keeping queueing delay under control when many users upload at once. Test loaded latency while saturating both download and upload; if latency rises dramatically, leave headroom or use proper queue management at the actual bottleneck.
When bandwidth limits are not the problem?
If only one area is slow, inspect RSSI/signal quality, interference, channel width, AP client count, Ethernet negotiation, and wireless backhaul before changing rate limits. If every AP is slow at the same time, compare WAN utilization and upstream latency. If speed is normal before authentication but poor after login, inspect controller shaping/session policy. This separation prevents repeatedly increasing ISP speed when the bottleneck is radio airtime—or repeatedly tuning Wi-Fi when the WAN is saturated.
Is a higher per-user limit always better?
No. A ceiling far above sustainable capacity can let a few heavy users build queues and increase latency for everyone. Choose limits from measured WAN capacity, peak concurrency, and the applications customers actually use.
Why is browsing slow even when a speed test looks fast?
Upload saturation, bufferbloat/queueing, DNS delay, packet loss, weak radio links, or an overloaded AP can hurt interactive use while a short download test still looks impressive. Measure loaded latency and the client/AP layer too.
Should I shape traffic on the controller and upstream router at the same time?
Only with a clear design. Multiple independent shapers can interact unpredictably. Put the primary queue policy at the actual bottleneck and understand what any platform-level per-user limit is adding.
How often should limits be reviewed?
Review after ISP changes and during real peak hours. If concurrent users, application mix, coverage, or backhaul changes, old limits can stop matching the service even when the configured numbers remain the same.
Useful next steps
Worked scenario: bandwidth settings
Piso WiFi Bandwidth and Speed Limit Settings: controller and router queue features differ; treat platform limits and upstream-router QoS as separate layers.
Illustrative case: One upload saturates the uplink while downloads appear acceptable. Compare latency under load and per-user shaping rather than advertising the ISP’s peak speed to every customer.
Documentation and scope