I am looking for a stack allowing to connect several hundred devices,
Openthread has max numbers of hopes equal 16.
Is it possible to extend that number to have 300 devices connected sequentially?
What are requirements to the chip in this case if possible or what limits the max number of connected routing devices?
The Thread Protocol Specification currently has a limit of 15 hops between routers (or 17 hops between end devices). It is not possible to connect hundreds of devices sequentially. At the same time, the Thread Protocol does connecting hundreds of end devices to each router. However, in most practical cases, the number of end devices a router supports is determined by its memory resources.
Related
I have a Gateway - Node application using the LoRa module but I don't know whether to choose the LoRa module to interface UART or SPI.
Can someone help me distinguish the difference when using these two types? Example: when I have 5 Nodes connected to Gatewway, which one should I use? and same when I have 50 Nodes.
Thanks!
A UART converts the signals to RS232 signaling(NOT VOLTAGES, You will need an additional adapter chip like the FTDI 232H) to hook up to a serial port on a computer. Speeds are usually limited to less than 400 Kilobits per second(varies based on distance and devices)
If you are connecting multiple devices to the same micro-controller(Arduino), use SPI. The connection speeds are not limited by standards. It is a bus arrangement with 4 pins (clock SCLK, input MISO, output MOSI and Slave select SS) The SCLK, MISO, MOSI are connected to all devices.To chain additional devices it requires an additional SS pin per device.
SPI is going to be faster(several (<5?)Megabits per second is not uncommon (depends on length(not greater than .3 meters), wire quality, environmental noise and device specifications) and requires less discrete components.
Since LoRa speeds max out around 300kbps, a single SPI connected gateway could theoretically handle 15 LoRa transceivers on a single gateway.
Doing 15 devices may violate local RF duty cycle restrictions resulting in fines and/or imprisonment.
Please check with your regulatory institutions prior to implementation of any solution.
I would suggest using four transceivers with external antennas each pointing in a different cardinal direction(possibly offset) at each gateway. This configuration should permit 400+(depending on usage patterns) client devices per gateway.
I have two Quadro K620 NVidia video cards. I want to compress 4 H.264 streams using NVENC SDK, 2 streams per card. video is 640x 480 30 fps.
2 streams working well without any problem but It's failed when I try to encod 3 Streams.
The function nvEncOpenEncodeSessionEx return NV_ENC_ERR_OUT_OF_MEMORY error in 3th stream.
Any idea?
Thanks.
This occurs due to a licensing limitations Please read this: "Following is the difference between licensing policies staring R358 driver(s) and the previous driver(s) . In driver(s) earlier to R358 , two simultaneous encoding sessions per system were allowed irrespective of the number of non - qualified GPUs present in the system. For example, on systems with one Quadro K4000 card and two GeForce cards, only two simultaneous encode sessions could be ru n, regardless of which GPU is running the encode session. Starting R358 , the restriction of two simultaneous encoding sessions will apply only to the combined number of sessions executed on all non - qualified cards . In the example above, the application can run N simultaneous encode sessions on Quadro K4000 card (where N is defined by the encoder/memory/hardware limitations) and two sessions on both GeForce cards combined. Thus the limit on the number of simultaneous encode sessions for such a system is N + 2"
A minimum board supports more than 2 NVENC threads in parallel is a QUADRO K2000 Please see NVENC SUPPOTED GPUs
I'm currently working a network protocol which includes a client-to-client system with auto-discovering of clients on the current local network.
Right now, I'm periodically broadsting over 255.255.255.255 and if a client doesn't emit for 30 seconds I consider it dead (then offline). The goal is to keep an up-to-date list of clients runing. It's working well using UDP, but UDP does not ensure that the packets have been sucessfully delivered. So when it comes to the WiFi parts of the network, I sometimes have "false postivives" of dead clients. Currently I've reduced the time between 2 broadcasts to solve the issue (still not working well), but I don't find this clean.
Is there anything I can do to keep a list of "online" clients without this risk of "false positives" ?
To minimize the false positives, due to dropped packets you should alter a little bit the logic of your heartbeat protocol.
Rather than relying on a single packet broadcast per N seconds, you can send a burst 3 or more packets immediately one after the other every N seconds. This is an approach that ping and traceroute tools follow. With this method you decrease significantly the probability of a lost announcement from a peer.
Furthermore, you can specify a certain number of lost announcements that your application can afford. Also, in order to minimize the possibility of packet loss using wireless network, try to minimize as much as possible the size of the broadcast UDP packet.
You can turn this over, so you will broadcast "ServerIsUp" message
and every client than can register on server. When client is going offline it will unregister, otherwise you can consider it alive.
I have an old hub that sucks, so I converted it to a USB-tripler by soldering all of the input 4 wires to the corresponding wires on the output connectors. I had to do this because modern devices require 2.0 or 2.8 volts on d+, and refuse to charge if d+ is shortened or not connected. It works well charging three devices from a 1a wall adapter.
But if someone accidentally connects this to a PC port, what will happen? Well if there is only one device, it would be detected no problem. But if two devices are wired to the same port, how dangerous is that?
I would prefer the first connected device to be identified in the system, while the second connected devices just get the power.
One of the first steps in USB enumeration is to send a reset signal by driving D+ and D- low. All the devices plugged in will see the reset and think it was intended for them. After the reset they will each think they have address 0 and respond to requests to that address. The result will be multiple devices trying to drive the bus at the same time, for a brief period before the host gives up.
I think it wouldn't damage anything, but you will be causing a short circuit for a few microseconds which is bad.
i would like build an only-audio conference system based on webrtc for a game, but i must avoid lag.
for example i can use https://github.com/muaz-khan/WebRTC-Experiment/tree/master/RTCMultiConnection
How many clients can be connected in the same time?and about bandwidth?
I think that the upload will be a limit increasing the amount of connected client.
Could i make a Tree of clients, so each client have only 2 or 3 connections?
The server can be in any language because i will use vert.x
regards
There are two scenarios:
1: Peer-to-Peer
In this model; maximum peer connections limit per page on chromium is 256.
2: Peer-to-Server
In this model; you can use media server to relay stream over unlimited peers.
In 1st model; you can face bandwidth/cpu usage issue.
In 2nd model; all such things are handled by the media server.
If you're planning to setup peer-to-peer video-conferencing; you'll use mesh model. It is suggested to limit conferencing to 5 users only. Otherwise, you'll face issues like audio-lost, echo and obviously bandwidth/cpu huge usage!
In broadcasting p2p scenarios; you can relay i.e. forward remote streams to overcome burden from single peer.