Hi, I'm building a LUX sensor based on the Lacrosse WS2500-19 brightness sensor protocol. I have used this info : http://www.f6fbb.org/domo/sensors/ws2500-19.php for the protocol. I'm pulsing the bit's as in the examples but RF-Link does not respond. This sensor is in the supported devices list so I was expecting it to work.
I have tested with TX3 timing and with WS7000 timing, both do not work. I have used this info for the timing : http://www.f6fbb.org/domo/sensors/index.php.
When looking in the development code I do see this sensor in Plugin_041.c but the type of sensors handled are Rain, Meteo and Wind, no Brighness type is returned.
Can any on confirm a working ws2500-19 sensor on RF-Link ? Thanks !
Lacrosse WS2500-19 brightness sensor
Moderators: rtenklooster, Voyager, BertB, Stuntteam
Re: Lacrosse WS2500-19 brightness sensor
might have been solved already.. see pm
-=# RFLink Gateway Development Team #=-
Introduction: http://www.nemcon.nl/blog2/
Generic Support forum: http://www.esp8266.nu/forum/viewforum.php?f=8
Introduction: http://www.nemcon.nl/blog2/
Generic Support forum: http://www.esp8266.nu/forum/viewforum.php?f=8
Re: Lacrosse WS2500-19 brightness sensor
I would like to use an arduino for emulating this Lacrosse WS2500-19 sensor , do you possible have some code i can use ?Rolo644u wrote: ↑28 Jul 2016, 09:11 Hi, I'm building a LUX sensor based on the Lacrosse WS2500-19 brightness sensor protocol. I have used this info : http://www.f6fbb.org/domo/sensors/ws2500-19.php for the protocol. I'm pulsing the bit's as in the examples but RF-Link does not respond. This sensor is in the supported devices list so I was expecting it to work.
I have tested with TX3 timing and with WS7000 timing, both do not work. I have used this info for the timing : http://www.f6fbb.org/domo/sensors/index.php.
When looking in the development code I do see this sensor in Plugin_041.c but the type of sensors handled are Rain, Meteo and Wind, no Brighness type is returned.
Can any on confirm a working ws2500-19 sensor on RF-Link ? Thanks !
Re: Lacrosse WS2500-19 brightness sensor
Perhaps not the most correct place for discussion for my setup, but at least here a discussion on implementation of the protocol for WS7000/19 respectively WS2500/19.
Since a few days a 'lookalike' of WS7000/19 (equivalent to WS2500/19) in test-operation in combination with RFLink_Gateway [version 46] providing data-output to Domoticz.
Not yet many observations, but it looks that
- at low lightlevel the readout displayed in Domoticz seems to be rather accurate
- for presently moderate & high lightlevels the readout in Domoticz seems off by a factor 10 (or even more), hinting to a scaling-issue.
Obviously as 1st element of the functional chain being checked that in the Sensor-Controller the data from the sensor MAX44009 is appropriately coded before transmission.
Following the transmission from the sensor then 2 elements in the functional chain that process the data:
- RLinkGateway
- Domoticz software.
Therefore the reason and/or the remedy for the scaling issue must be found 'somewhere' in the sequential operation of those 3 elements.
Looking in the data-protocol for WS2500/19&WS7000/19 and the links in the previous messages this difference might be attributed to the F-bits, used in the message to send the 'multiplier' Facteur [=F].
From the data-protocol I deduct that a kind of 'gear-shifting' takes place for the filling of the message:
Low lightlevel => the measured lightvalue xyz directly fits in the range of the 3*4 L-bits => translates into (xyz) with F~1 => output value = 1*(1*x + 10*y + 100*z)
Higher lightlevel => the measured lightvalue approximates 10*(abc) => translates for the 3*4 L-bits into (abc) with F~10 => output value = 10*(1*a + 10*b + 100*c)
etc.
Is this interpretation correct?
Within the range of the L-bit segment of 0 ~ 999, in that way still very high lightlevels can be reported, although with decreasing resolution for increasing lightlevels.
'Gear-shifting' provides following message-contents:
F=0 => Multiplier = 10^0 = 1 => values 0 ~ 999 Lux with resolution of 1 Lux
F=1 => Multiplier = 10^1 = 10 => values 0 ~ 9990 Lux with resolution of 10 Lux
F=2 => Multiplier = 10^2 = 100 => values 0 ~ 99900 Lux with resolution of 100Lux
etc.
Anybody with similar observations as described in the second dash of the second section?
With a 'real' WS7000/19 or WS2500/19, or with a 'look-alike'?
Reason & remedy known?
BTW, anybody having a good, clear description how the M-bit segment is used (or might be used, e.g. to calculate sunshine-hours)?
Since a few days a 'lookalike' of WS7000/19 (equivalent to WS2500/19) in test-operation in combination with RFLink_Gateway [version 46] providing data-output to Domoticz.
Not yet many observations, but it looks that
- at low lightlevel the readout displayed in Domoticz seems to be rather accurate
- for presently moderate & high lightlevels the readout in Domoticz seems off by a factor 10 (or even more), hinting to a scaling-issue.
Obviously as 1st element of the functional chain being checked that in the Sensor-Controller the data from the sensor MAX44009 is appropriately coded before transmission.
Following the transmission from the sensor then 2 elements in the functional chain that process the data:
- RLinkGateway
- Domoticz software.
Therefore the reason and/or the remedy for the scaling issue must be found 'somewhere' in the sequential operation of those 3 elements.
Looking in the data-protocol for WS2500/19&WS7000/19 and the links in the previous messages this difference might be attributed to the F-bits, used in the message to send the 'multiplier' Facteur [=F].
From the data-protocol I deduct that a kind of 'gear-shifting' takes place for the filling of the message:
Low lightlevel => the measured lightvalue xyz directly fits in the range of the 3*4 L-bits => translates into (xyz) with F~1 => output value = 1*(1*x + 10*y + 100*z)
Higher lightlevel => the measured lightvalue approximates 10*(abc) => translates for the 3*4 L-bits into (abc) with F~10 => output value = 10*(1*a + 10*b + 100*c)
etc.
Is this interpretation correct?
Within the range of the L-bit segment of 0 ~ 999, in that way still very high lightlevels can be reported, although with decreasing resolution for increasing lightlevels.
'Gear-shifting' provides following message-contents:
F=0 => Multiplier = 10^0 = 1 => values 0 ~ 999 Lux with resolution of 1 Lux
F=1 => Multiplier = 10^1 = 10 => values 0 ~ 9990 Lux with resolution of 10 Lux
F=2 => Multiplier = 10^2 = 100 => values 0 ~ 99900 Lux with resolution of 100Lux
etc.
Anybody with similar observations as described in the second dash of the second section?
With a 'real' WS7000/19 or WS2500/19, or with a 'look-alike'?
Reason & remedy known?
BTW, anybody having a good, clear description how the M-bit segment is used (or might be used, e.g. to calculate sunshine-hours)?
Last edited by Ton_vN on 31 Mar 2020, 10:21, edited 3 times in total.
Re: Lacrosse WS2500-19 brightness sensor
The communication between WS7000-19-'clone' and an original WS2500-receiver has been checked: looks OK
Domoticz most probably just shows what RFLinkGateway presents.
.
Last days with clear-blue sky and plenty of sunshine gave ample opportunity to check the operation of the 'chain' with WS7000-19 => RFLinkGateway => Domoticz.
Compared in Domoticz the readings by a colocated sensor type SI1145 (= upper graph) with the info from WS7000-19 (= bottom graph).
The graph from SI1145 is rather smoothly rising in the morning.
In the resulting curve at Domoticz for WS7000-19 it can be clearly seen that
- the line starts indicating the L-value (with F=0 => multiplier = 1)
- the line at the 1st threshold drops back to an L-value which is representative for L/10 ( at that moment should be with F=2 => multiplier = 10).
- that process repeats itself at the 2nd thresholdlevel for L/100 (& F=3 => multiplier = 100).
Looking at the numbers in both graphs, a resemblance can be seen between SI1145 and WS700-19-'clone'.
However, for F>0 the value shown for WS7000-19 seems to be lagging by a factor 10.
At this moment apparently the handling of some F-values is missing 'somewhere' in the interfaces & functions around RFLinkGateway & Domoticz
.
Domoticz most probably just shows what RFLinkGateway presents.
.
Last days with clear-blue sky and plenty of sunshine gave ample opportunity to check the operation of the 'chain' with WS7000-19 => RFLinkGateway => Domoticz.
Compared in Domoticz the readings by a colocated sensor type SI1145 (= upper graph) with the info from WS7000-19 (= bottom graph).
The graph from SI1145 is rather smoothly rising in the morning.
In the resulting curve at Domoticz for WS7000-19 it can be clearly seen that
- the line starts indicating the L-value (with F=0 => multiplier = 1)
- the line at the 1st threshold drops back to an L-value which is representative for L/10 ( at that moment should be with F=2 => multiplier = 10).
- that process repeats itself at the 2nd thresholdlevel for L/100 (& F=3 => multiplier = 100).
Looking at the numbers in both graphs, a resemblance can be seen between SI1145 and WS700-19-'clone'.
However, for F>0 the value shown for WS7000-19 seems to be lagging by a factor 10.
At this moment apparently the handling of some F-values is missing 'somewhere' in the interfaces & functions around RFLinkGateway & Domoticz
.
- SI1145 Run_up in morning
- SI1145Lux_20200327 [640x480].jpeg (20.86 KiB) Viewed 28245 times
- WS7000_19 Run_up in morning
- WS7000P19_20200327 [640x480].jpeg (23.94 KiB) Viewed 28245 times
Re: Lacrosse WS2500-19 brightness sensor
Stuntteam provided RFLink-firmware testversion v49.4
Running smooth, generating plausible outputvalues for lightmeasurement from my WS7000-19-Clone.
One more step forward!
With this emulation of WS2500/19 aka WS7000/19, under application of this updated firmware for RFLinkGateway,
Domoticz now gets the transmitted lightvalues as defined for that 433MHz-interface.
All combinations of F-values and L-values applicable for the practical light values!
My clone as input applies a sensor MAX44009, consuming very low power, combining an IR-sensor and Light-sensor to mimick the human eye, and
measuring with an ultra-wide 22-bit dynamic range from 0.045 lux to 188,000 lux.
An I2C-buffer makes the MAX44009 compatible with the 2*SHT31 which are part of the configuration.
Running smooth, generating plausible outputvalues for lightmeasurement from my WS7000-19-Clone.
One more step forward!
With this emulation of WS2500/19 aka WS7000/19, under application of this updated firmware for RFLinkGateway,
Domoticz now gets the transmitted lightvalues as defined for that 433MHz-interface.
All combinations of F-values and L-values applicable for the practical light values!
My clone as input applies a sensor MAX44009, consuming very low power, combining an IR-sensor and Light-sensor to mimick the human eye, and
measuring with an ultra-wide 22-bit dynamic range from 0.045 lux to 188,000 lux.
An I2C-buffer makes the MAX44009 compatible with the 2*SHT31 which are part of the configuration.
Re: Lacrosse WS2500-19 brightness sensor
After upgrade of the firmware of RFLinkGateway and WS_Controller, the WS7000P19 was coupled to Domoticz via RFLinkGateway.
One year later looked at the year-graphs from Domoticz and surprised to see that apparently a clamping is taking place at light level of approx. 65kLux.
Any user of RFLinkGateway in conjunction with Lightsensor WS2500/19 or WS7000/19 seeing similar graph?
Obvious next question: where in functional chain Sensor > RFLinkGateway > Domoticz is this clamping happening?
At this moment difficult to check, because lightlevels too low till next spring to serve as input >65kLux.
For reference/comparison the light-curve from my Tempest PWS over the period starting April 2021 in which the higher lightlevels occur, and clearly show.
One year later looked at the year-graphs from Domoticz and surprised to see that apparently a clamping is taking place at light level of approx. 65kLux.
Any user of RFLinkGateway in conjunction with Lightsensor WS2500/19 or WS7000/19 seeing similar graph?
Obvious next question: where in functional chain Sensor > RFLinkGateway > Domoticz is this clamping happening?
At this moment difficult to check, because lightlevels too low till next spring to serve as input >65kLux.
- WS7000P19_Yeargraph
- chart_WS7000P19year_210927.jpeg (69.04 KiB) Viewed 21303 times
- Tempest_Yeargraph
- chart_Tempest_year_210927.jpeg (75.9 KiB) Viewed 21299 times
Re: Lacrosse WS2500-19 brightness sensor
The proper solution is: research & test, finding the source of the problem and subsequent correction of related firmware.
However, it involves at least 2 elements (WS7000P19-Controller and RFLinkGateway) and bright light (> 100kLux) is needed for reproduction of the problem.
Not nice, but very pragmatic remedy for this 'problem' is following make-shift solution.
Basic approach:
If the electronic & software functions 'somewhere' in the functional chain cause the described clamping, then reduce the input at the sensor so much that no clamping occurs.
In this case it means that a real input of approx. 150kLux should result in a virtual lightlevel on the sensor of approx. 60kLux.
=> find an optical attenuation filter of approx. 2,5* and put as cover over the sensor
=> while getting actual lightlevels of 0 ~150kLux, the sensor will effectively 'see' 0 ~60kLux
=> multiply the resulting, reported value in Domoticz by 2.5* to reconstruct the entry-value
During earlier testing with firmware 0.0. a
deodorantroller-cap provided physical attenuation for a similar situation.
Is really try&error to find a suitable cap, because most caps deliver more attenuation and are not 'uniform' in all critical directions.
After finding a suitable cap the most difficult part of the implementation is to exactly determine how much attenuation from the cap:
you temporarily need a well calibrated light measuring device.
Considering the occurence of clamping I have time till next april to find a better solution ..........
However, it involves at least 2 elements (WS7000P19-Controller and RFLinkGateway) and bright light (> 100kLux) is needed for reproduction of the problem.
Not nice, but very pragmatic remedy for this 'problem' is following make-shift solution.
Basic approach:
If the electronic & software functions 'somewhere' in the functional chain cause the described clamping, then reduce the input at the sensor so much that no clamping occurs.
In this case it means that a real input of approx. 150kLux should result in a virtual lightlevel on the sensor of approx. 60kLux.
=> find an optical attenuation filter of approx. 2,5* and put as cover over the sensor
=> while getting actual lightlevels of 0 ~150kLux, the sensor will effectively 'see' 0 ~60kLux
=> multiply the resulting, reported value in Domoticz by 2.5* to reconstruct the entry-value
During earlier testing with firmware 0.0. a
deodorantroller-cap provided physical attenuation for a similar situation.Is really try&error to find a suitable cap, because most caps deliver more attenuation and are not 'uniform' in all critical directions.
After finding a suitable cap the most difficult part of the implementation is to exactly determine how much attenuation from the cap:
you temporarily need a well calibrated light measuring device.
Considering the occurence of clamping I have time till next april to find a better solution ..........
Re: Lacrosse WS2500-19 brightness sensor
Maybe you can also try one of those ND filters.
Those have a known attenuation for light (on various wavelengths, but should be "neutral" to colors) which makes testing probably a lot simpler.
With your cap it is impossible to know the attenuation of light for a given wave length.
Also it could be that this spectral response may shift when the cap heats up.
Those have a known attenuation for light (on various wavelengths, but should be "neutral" to colors) which makes testing probably a lot simpler.
With your cap it is impossible to know the attenuation of light for a given wave length.
Also it could be that this spectral response may shift when the cap heats up.
Re: Lacrosse WS2500-19 brightness sensor
@TDer
Completely agreed, and reason/background for the italic text in line 3:
it is a practical circumvention of the problem of clamping, nothing better than that.
My feeling is that the proper solution is described in line 2 of my previous message, but that takes time ......
Completely agreed, and reason/background for the italic text in line 3:
it is a practical circumvention of the problem of clamping, nothing better than that.
My feeling is that the proper solution is described in line 2 of my previous message, but that takes time ......
Re: Lacrosse WS2500-19 brightness sensor
If you want, I can also 3D print an adapter for you.
For example a simple clamp on the tube and on the other end a ring adapter for a filter ring.
For example a simple clamp on the tube and on the other end a ring adapter for a filter ring.
Re: Lacrosse WS2500-19 brightness sensor
It took quite long time to get perfect weather for this test, but recently a few continuously very bright & very clear days gave opportunity to make 'unspoiled' loggings of the transmission for highlevellightdata from the WS7000-Controller towards the RFLinkGateway.
Analysis of the best logging made in the RFLinkGateway shows that 22nd of June later than 11:15 the pulse-pattern is telling that the level should be > 65klux,
but the RFLinkGateway 'shifts gear downward' and via Domoticz (as in the picture below) shows level below 65klux.
Apparently MSB present from the Controller, but missing in the data from RFLinkGateway to Domoticz.
.
Reported to RFLinkStuntteam, and now waiting for response.
.
Analysis of the best logging made in the RFLinkGateway shows that 22nd of June later than 11:15 the pulse-pattern is telling that the level should be > 65klux,
but the RFLinkGateway 'shifts gear downward' and via Domoticz (as in the picture below) shows level below 65klux.
Apparently MSB present from the Controller, but missing in the data from RFLinkGateway to Domoticz.
.
Reported to RFLinkStuntteam, and now waiting for response.
.
- WS7000P19 Highlightlevel
- WS7000P19chart20220622.png (99.68 KiB) Viewed 18456 times
Re: Lacrosse WS2500-19 brightness sensor
This weekend's bright, sunny, cloudless days with high light level invite for more testing, but first need response from the RFLinkStuntteam with firmware-update from v49.4, otherwise just 'repeat'.
Re: Lacrosse WS2500-19 brightness sensor
It's noted but due to vacations it will take a while..
-=# RFLink Gateway Development Team #=-
Introduction: http://www.nemcon.nl/blog2/
Generic Support forum: http://www.esp8266.nu/forum/viewforum.php?f=8
Introduction: http://www.nemcon.nl/blog2/
Generic Support forum: http://www.esp8266.nu/forum/viewforum.php?f=8
Re: Lacrosse WS2500-19 brightness sensor
Summer vacation now probably forgotten.
Or interference from upcoming vacation?
Outdoors not much light available for testing, but might give time for testing of script-update as companion of some other update of the firmware.
Or interference from upcoming vacation?Outdoors not much light available for testing, but might give time for testing of script-update as companion of some other update of the firmware.
Re: Lacrosse WS2500-19 brightness sensor
Er zijn zeker dringender aspecten om te verbeteren voor de RFLinkGateway-firmware, en de praktische lichtniveau's zijn momenteel heel ver beneden het 'probleem-gebied' > 65kLux, zoals ontdekt in firmware-testversie V49.4
maar dat geeft juist tijd om te kijken hoe voor deze correctie de firmware bijgewerkt kan worden, 'meeliftend' met andere aanpassingen.
Reactie wordt op prijs gesteld.
maar dat geeft juist tijd om te kijken hoe voor deze correctie de firmware bijgewerkt kan worden, 'meeliftend' met andere aanpassingen.
Reactie wordt op prijs gesteld.
Re: Lacrosse WS2500-19 brightness sensor
Very clear sky today and nice spring weather is good for testing the readout for high levels of Light and UVI.
.
The graph below well demonstrates that the RFLinkGateway does not process the MSB of 65kLux for WS7000P19:
between today approx. 10:30 and 16:00 the graphline 'dips', although a level higher than 65kLux is expected,
Tempest-readout for comparison shows levels running up to 133kLux.
The sensor MAX44009 of WS7000P19 is also able to 'see' those values within it's technical range of 188kLux,
and therefore it would be nice if RFLinkGateway would correctly transfer the actual value.
Included in the next upgrade of the firmware for RFLinkGateway?
.
.
The graph below well demonstrates that the RFLinkGateway does not process the MSB of 65kLux for WS7000P19:
between today approx. 10:30 and 16:00 the graphline 'dips', although a level higher than 65kLux is expected,
Tempest-readout for comparison shows levels running up to 133kLux.
The sensor MAX44009 of WS7000P19 is also able to 'see' those values within it's technical range of 188kLux,
and therefore it would be nice if RFLinkGateway would correctly transfer the actual value.
Included in the next upgrade of the firmware for RFLinkGateway?
.
- Comparatative Light-graph
- piVergelijk1Light230608.png (50.83 KiB) Viewed 16387 times
Re: Lacrosse WS2500-19 brightness sensor
A fix for this aspect to be included in upcoming upgrade R50?
Re: Lacrosse WS2500-19 brightness sensor
From 'repair' of the BH1750 in my DIY-setup now have a spare Dome for a BH1750.
In that DIY-setup have to calibrate/align the BH1750-with-dome and the TLS2561s:
that would provide data how much the dome is attenuating, and such data might be interesting to consider the spare dome as cap over the MAX44009.
First observation is that attenuation is approx. 3*
As makeshift interim solution pending a preferred upgrade of the RFLinkGateway's firmware,
it provides a practical (but inaccurate) range extension from max. 65kLux towards max. 195kLux.
For 2023 not an urgent matter, because the actual, practical values for 'naked' MAX44009 presently under 65kLux and seasonrelated decreasing.
In that DIY-setup have to calibrate/align the BH1750-with-dome and the TLS2561s:
that would provide data how much the dome is attenuating, and such data might be interesting to consider the spare dome as cap over the MAX44009.
First observation is that attenuation is approx. 3*
As makeshift interim solution pending a preferred upgrade of the RFLinkGateway's firmware,
it provides a practical (but inaccurate) range extension from max. 65kLux towards max. 195kLux.
For 2023 not an urgent matter, because the actual, practical values for 'naked' MAX44009 presently under 65kLux and seasonrelated decreasing.
Re: Lacrosse WS2500-19 brightness sensor
Winter 2023-2024 provides plenty of time to implement a firmware-update before the high range is again needed in spring/summer of 2024:
when is firmware-update released?
when is firmware-update released?
Re: Lacrosse WS2500-19 brightness sensor
Don't see it specifically mentioned in the description of mods,
but has this 'required upgrade' for WS2500/19 aka WS7000/19 been included in version 1.1 R50 for the RFLink-firmware?
but has this 'required upgrade' for WS2500/19 aka WS7000/19 been included in version 1.1 R50 for the RFLink-firmware?
Re: Lacrosse WS2500-19 brightness sensor
RFLink-firmware requires an upgrade (as requested since July 2022) to get satisfactory operation of light-sensor WS2500/19 aka WS7000/19 with correct MSB-handling.
No sign that such WS7000/19-update according to test-firmware v49.4 has been incorporated in any firmware upto/incl. v51.
Because neither any reaction from the Stuntteam, have to assume that no longer an upgrade-inclusion is being planned.
Consequence:
Correct RFLink-operation for WS2500/19 and WS7000/19 as well as clones of those devices is not possible for lightlevels >65kLux due to faulty firmware.
For my configuration no other practical solution left than continued use for RFLinkGateway of the test-firmware v49.4
plus pragmatically putting an attenuation cap over the Lightsensor of my WS7000/19-clone to reduce sensor-level within range of RFLink-handling
plus multiply the output by a general correction-factor.
Calibration? Forget it => the lightsensor just becomes a rough indicator for lightlevel.
No sign that such WS7000/19-update according to test-firmware v49.4 has been incorporated in any firmware upto/incl. v51.
Because neither any reaction from the Stuntteam, have to assume that no longer an upgrade-inclusion is being planned.
Consequence:
Correct RFLink-operation for WS2500/19 and WS7000/19 as well as clones of those devices is not possible for lightlevels >65kLux due to faulty firmware.
For my configuration no other practical solution left than continued use for RFLinkGateway of the test-firmware v49.4
plus pragmatically putting an attenuation cap over the Lightsensor of my WS7000/19-clone to reduce sensor-level within range of RFLink-handling
plus multiply the output by a general correction-factor.
Calibration? Forget it => the lightsensor just becomes a rough indicator for lightlevel.
Re: Lacrosse WS2500-19 brightness sensor
It has been fixed and tested.
It will be in the upcoming release (52).
It will be in the upcoming release (52).
-=# RFLink Gateway Development Team #=-
Introduction: http://www.nemcon.nl/blog2/
Generic Support forum: http://www.esp8266.nu/forum/viewforum.php?f=8
Introduction: http://www.nemcon.nl/blog2/
Generic Support forum: http://www.esp8266.nu/forum/viewforum.php?f=8
Re: Lacrosse WS2500-19 brightness sensor
Thanks!
For next summer finally getting rid, either of that upper limit clamping, or the use of an attenuation-cap ..............
.
.
Simplest attenuation-cap is from deodorantroller, internally smoothed to get uniform thickness of the 'wall'.
By earlier experience this pink version has an attenuation-factor of approx. 3
For next summer finally getting rid, either of that upper limit clamping, or the use of an attenuation-cap ..............
.
- Readout by Domoticz (behind) RFLinkGTW) for lightlevel of WS7000P19
- chart_WS7000P19_2023 [640x480].jpeg (42.08 KiB) Viewed 13464 times
- WS7000P19_capped
- WS7000P19_capped [50%].jpg (24.41 KiB) Viewed 13364 times
By earlier experience this pink version has an attenuation-factor of approx. 3
Who is online
Users browsing this forum: No registered users and 0 guests