Meteobridge communication problem with the UV sensor!

[admin]

Can you solve this problem, in a way that you will choose, since you have rejected the solution I proposed above?

Not sure what kind of "solution" you offered.

[zakos52]

Not sure what kind of "solution" you offered.

"-Can the time that the meteostick receives the packets change from 12sec to 6sec, so that there are no gaps in the UV chart?
-No"

Can you solve this problem, in a way that you will choose, since you have rejected the solution I proposed above?

Thanks

[Mattk]

Not sure what kind of "solution" you offered.

"-Can the time that the meteostick receives the packets change from 12sec to 6sec, so that there are no gaps in the UV chart?
-No" ....

Just curious, are you the only one that has this particular problem or is it across the board? Normally when there is a common issue there will be others with the same issue?

[zakos52]

Just curious, are you the only one that has this particular problem or is it across the board? Normally when there is a common issue there will be others with the same issue?

In your opinion, how many people must have this problem for there to be a solution?

[Mattk]

Just curious, are you the only one that has this particular problem or is it across the board? Normally when there is a common issue there will be others with the same issue?

In your opinion, how many people must have this problem for there to be a solution?

Depends what the solution is, I suppose? So why will reducing the time from 12 to 6 seconds change sensor data that it itself updates every 50 seconds or so?

[zakos52]

Depends what the solution is, I suppose? So why will reducing the time from 12 to 6 seconds change sensor data that it itself updates every 50 seconds or so?

I think the problem starts with the long time intervals during which the UV sensor sends data (every 50sec to 1min)

The meteobridge tries to retrieve the data every 12 to 13 sec. Most of the time this is possible. However, there are certain moments in time when it fails to "hear" the data.

So if the search time is reduced from 12 to 6 sec, then the probability of not receiving data from the UV sensor will be reduced to zero!

I hope this is understandable!

PS
If this solution is not possible, I hope the admin will suggest another one to eliminate the problem with the gaps in the UV diagram.

[Mattk]

Depends what the solution is, I suppose? So why will reducing the time from 12 to 6 seconds change sensor data that it itself updates every 50 seconds or so?

I think the problem starts with the long time intervals during which the UV sensor sends data (every 50sec to 1min)

The meteobridge tries to retrieve the data every 12 to 13 sec. Most of the time this is possible. However, there are certain moments in time when it fails to "hear" the data.

So if the search time is reduced from 12 to 6 sec, then the probability of not receiving data from the UV sensor will be reduced to zero!

I hope this is understandable!

PS
If this solution is not possible, I hope the admin will suggest another one to eliminate the problem with the gaps in the UV diagram.

So in your opinion, why don't others have this problem?

[zakos52]

So in your opinion, why don't others have this problem?

The point is to find a solution and not to count how many people have the same problem!

But as far as I understand, you are concerned with the number of those who have a problem and not the solution to the problem!

Pity!

[Mattk]

So in your opinion, why don't others have this problem?

The point is to find a solution and not to count how many people have the same problem!

But as far as I understand, you are concerned with the number of those who have a problem and not the solution to the problem!

Pity!

No not all all, just concerned why only one(1) has come forward that has this problem and who really doesn't know where this so called issue actually exists.

As previously mentioned I don't have a UV sensor, but have Solar sensors on multiple systems across MBPro's, MBPro2's, Nano's and NanoSD's integrated with Envoys, VP2 ISS including WLIP's which is why I can raise the question especially considering there is basically nothing different comms wise between a UV and Solar sensor.

So again I ask you the question why can not I duplicate your issue across any of my systems? What is different with your setup?

[admin]

Not sure what kind of "solution" you offered.

"-Can the time that the meteostick receives the packets change from 12sec to 6sec, so that there are no gaps in the UV chart?
-No"

Can you solve this problem, in a way that you will choose, since you have rejected the solution I proposed above?

Looks like you do not understand how data is read via RF. Meteobridge is listening into the air to pick-up every Vantage data packet it can read. Meteobridge does not decide how often the ISS does send data. It is a one way protocol only: ISS sends, Meteobridge listens. The interval between data packets depends slightly on the used transmitter ID (this interval drift is meant to avoid multiple ISS on different IDs wiping out their data over a longer period). Meteobridge syncs to the flow of received packets. Therefore your "6 secs VS 12 secs" idea is pure fantasy, not factual at all.

Did you try using another transmitter ID? May be there is some interference with other stations?

[zakos52]

Did you try using another transmitter ID? May be there is some interference with other stations?

1. There is no other Davis station sending data!

2.ISS transmits on ID 2 and console relays on ID 3.

3. Tried retransmitting on ID 1, ID 4, ID5, ID6, ID7 and ID 8 with no result!

4. Note that in all the above channels the meteobridge receives data from the ISS every 12 to 13 sec!

5. Look at this image again. The meteostick has been trying for 32 minutes to get data from the UV sensor!
I think there is no way the UV sensor is not sending data for 32 minutes!

UV MAX1.png (7.92 KiB) Viewed 2025 times

[zakos52]

-As previously mentioned I don't have a UV sensor, but have Solar sensors on multiple systems across MBPro's, MBPro2's, Nano's and NanoSD's integrated with Envoys, VP2 ISS including WLIP's which is why I can raise the question especially considering there is basically nothing different comms wise between a UV and Solar sensor.
So again I ask you the question why can not I duplicate your issue across any of my systems? What is different with your setup?

The idea that the UV sensor communicates like the solar is an assumption on your part! But there may be some difference, which is not known since you do not have it in your possession!

Therefore, you cannot do any simulation with the material you have!

[Mattk]

-As previously mentioned I don't have a UV sensor, but have Solar sensors on multiple systems across MBPro's, MBPro2's, Nano's and NanoSD's integrated with Envoys, VP2 ISS including WLIP's which is why I can raise the question especially considering there is basically nothing different comms wise between a UV and Solar sensor.
So again I ask you the question why can not I duplicate your issue across any of my systems? What is different with your setup?

The idea that the UV sensor communicates like the solar is an assumption on your part! But there may be some difference, which is not known since you do not have it in your possession!

Therefore, you cannot do any simulation with the material you have!

Not exactly but pretty dam close and close enough based on the specs of the UV and solar sensor. The other thing that has also stood out with this is your signal -db, way over the top?

[zakos52]

Not exactly but pretty dam close and close enough based on the specs of the UV and solar sensor. The other thing that has also stood out with this is your signal -db, way over the top?

meteobridge.png (50.47 KiB) Viewed 1999 times

[Mattk]

Referring to the Live data Signal being in the sub -20db, such as UV signal of -14db and -18db? Have a couple of systems that literally sit on top of each other in repeater and non repeater configs and see around -40db signal strength so looking at what might appear odd or abnormal in your config.

The problem is when trying to diagnose something like this one only get to see what limited output is provided.