Welcome Inspire Pilots!
Join our free DJI Inspire community today!
Sign up

Question in regards to controllers...

Joined
Jan 16, 2021
Messages
178
Reaction score
77
Age
53
Hey guys, so, I have searched and searched and still not found any good references to the various controllers for the Inspire 1.

Now, the reason I am bringing this up is because I have 2 GL658A (master/slave original units) controllers with my Inspire 1 V1, I also have a GL658B (single) with my Inspire 1 V2 and I purchased 2 additional controllers, both being GL658C controllers. I plan on using the GL658C controllers with the V2 craft because of the higher output of both the craft and the controllers. But that is where the questions start...

In my searching it would seem as if the GL658A was used on V1s, that is all. It would seem that at some point they started producing GL658B controllers during V1 production before the time they released the V2. All Inspire 1 V2s shipped with either GL658B or GL658C controllers, never GL658A controllers.

Now, even though DJI states they are all the same, I have seen where people said if you have a GL658B and a GL658C with a V2 you should use the GL658B as the master. I have also read that via the FCC listings that the GL658C has almost 2x-3x the power the GL658B has.

So, I have also read that the V2 has a much more powerful radio to match the GL658C controller, resulting in better range.

Now, it would seem that none of this matters as firmware beyond 1.08.x.x AC/1.6.x RC seriously kneecaps the radios and it would seem all combinations get crappy range on the later firmwares.

Since there is no single definitive reference, I figured I would post this and hopefully get this answered once and for all.

To sum up:

GL658A - Original power level - Original with Inspire 1 V1
GL658B - Original power level - Middle revision for Inspire 1 V1, shipped with early Inspire 1 V2 models
GL658C - Higher power level - Later revision, only shipped with Inspire 1 V2


Now, if we could get some details on each revision, such as which is better for master and slave, which ones have 5.8Ghz issues as master/slave and which ones are known to work best in which configuration, that would be ideal.
 
Last edited:
To follow-up I figured an all original V1 would work well with the GL658A controllers as both master/slave.

For the V2 setup, can I assume using a GL658C as a master (for extended range) would be best with the GL658B as the slave? (or should the other GL658C be the slave???)

I mean, personally, it would seem like a waste to use the GL658C as a slave. especially if it has a higher power radio. I mean, in that case, if the C/B combo is preferred on the V2, would I gain anything by replacing the A controller as master for the V1 with the C controller?

I just want to get everything set and know it is proper and "best set"... I would rather not dink around with various setups to try to figure out which is "best".

I am sure there are lots of people that have figured all of this out by now.

All input is appreciate.
 
Ok, to add some more info I gleaned from posted FCC reports (all rounded to nearest dBm):

GL658A - Peak Power: 26dBm - Average Power: 14dBm
GL658B - Peak Power: 25dBm - Average Power: 12dBm
GL658C - Peak Power: 29dBm - Average Power: 16dBm

So the "C" is the most powerful (as previously reported), with the "A" being about just less than half the power output (-3dBm is half the power) and "B" is the weakest at -4dBm from the "C" radio.

I also read where the "B" controller was primarily marketed as a "add-on" controller. ie, they expected you to use the B controller as the "add-on" slave to a "A" or "C" controller. How true this is or not I don't know, but seeing the power output differences, I wouldn't doubt it.

So, It would seem that I should put the "C" controllers as the "Master" controller for both setups and relegate the "A" or "B" controllers to be the slaves. Or at least the "B" should always be a slave and never a master under these specs.

I wonder if all the problems people had using "C" controllers as slaves with video transmission issues is because of the higher output specs. I have yet to see where anyone stated that going with a "A" master and "B" slave worked well. I haven't even seen where someone said a "C" master and "B" slave worked well. (Conversely, I HAVE seen where a "B" master and "C" slave had issues, but the guy never posted back about swapping them and then seeing how they work, but it would be interesting to see a "C" master and "A" slave configuration to see how it works out.)
 
Mr. Fist;

You are doing what most of us do. You ask a bunch of questions, but then dive a little deeper into your own research to find your own answers. Your next step will be to conduct your own experiments, record your results and make a video. Considering that it takes mere seconds to link a DJI controller to a DJI drone, and considering that you are one of very few who actually owns all 3 versions of the Inspire controllers, this is a great opportunity for you to conduct real-world field tests and report your results. I had a similar journey with different firmware versions. Completely unsatisfied with the BS "information" I garnered from DJI, I simply conducted my own tests and made a video about it.


Good luck.

D
 
  • Like
Reactions: The Editor
Donnie, I hear ya, I really do.

My biggest issue right now is the fact we are in the dead of winter in cold and snow-laden Wisconsin. If it was even springtime I would most certainly be doing structured tests and posting results. As it is I am fairly well restricted.

Since these setups are new to me I am doing a set of battery tests first to first establish that I can have a certain amount of confidence in making sure I won't lose an Inspire while I am testing. I have already had a situation where a battery with 80% charge that I used to only do a firmware update on prior caused a "Low Voltage - Landing" warning out of the blue when I was testing the firmware update directly there-after (I will note that after a complete discharge and recharge it seems to be functioning normal on a subsequent flight). After I am done with those tests and have a suitable amount of confidence in being able to fly over distance I will then do exactly like you mentioned and formulate a set of tests that prove out some of the theories that have been mulled about but not answered.

I am just kinda shocked that no-one has done any of this in a more empirical manner to determine what the best combinations are.

For certain I will state that it seems like "C" master and "C" slave have issues. Which is not surprising if they are as powerful as stated (ie, hard to communicate when everything is amplified to max).

I will also do tests with both V1 and V2 N-Cores on both the latest 1.11.x.x firmware and the "known good" 1.8.x.x firmwares to ascertain how the firmware affect performance and reliability as well.

Now, does anyone think that having to worry about the DJI Go version used is something that is necessary? I only bring that up because from a "systems" point of view the app itself has nothing to do with how the radios operate, has nothing to do with how the these type of tests will give results and I think they are mature enough to not impose any issues in regards to video output or monitoring of systems that would affect the results either. Again, if anyone thinks otherwise I would like to visit those issues before I start.
 
Last edited:
Donnie, I hear ya, I really do.

My biggest issue right now is the fact we are in the dead of winter in cold and snow-laden Wisconsin. If it was even springtime I would most certainly be doing structured tests and posting results. As it is I am fairly well restricted.

Since these setups are new to me I am doing a set of battery tests first to first establish that I can have a certain amount of confidence in making sure I won't lose an Inspire while I am testing. I have already had a situation where a battery with 80% charge that I used to only do a firmware update on prior caused a "Low Voltage - Landing" warning out of the blue when I was testing the firmware update directly there-after (I will note that after a complete discharge and recharge it seems to be functioning normal on a subsequent flight). After I am done with those tests and have a suitable amount of confidence in being able to fly over distance I will then do exactly like you mentioned and formulate a set of tests that prove out some of the theories that have been mulled about but not answered.

I am just kinda shocked that no-one has done any of this in a more empirical manner to determine what the best combinations are.

For certain I will state that it seems like "C" master and "C" slave have issues. Which is not surprising if they are as powerful as stated (ie, hard to communicate when everything is amplified to max).

I will also do tests with both V1 and V2 N-Cores on both the latest 1.11.x.x firmware and the "known good" 1.8.x.x firmwares to ascertain how the firmware affect performance and reliability as well.

Now, does anyone think that having to worry about the DJI Go version used is something that is necessary? I only bring that up because from a "systems" point of view the app itself has nothing to do with how the radios operate, has nothing to do with how the these type of tests will give results and I think they are mature enough to not impose any issues in regards to video output or monitoring of systems that would affect the results either. Again, if anyone thinks otherwise I would like to visit those issues before I start.
Touché. I didn't know you were in Wisconsin. Let me get you started on the right foot with my FW/SW versions for all 3 of our Inspire 1's. My business partner owns the Inspire V1 and the Inspire Pro. I own the Inspire 1 V2. All 3 birds, all 5 remotes and all 5 iPads all run the same Firmware / Software. We have complete consistency across all platforms and amazing reliability and usability.

Go App: v3.1.1
App database: v00.00.01.04
Aircrafts: v1.8.1.00
Remotes: v1.6
X3 Cameras: v1.8.1
X5 Camera: v1.11.1.50

I should warn you that rolling back from Firmware version 1.11.xx has been dicey. If your bird(s) is/are on v1.08.xx, I would leave them there. Here's why:


Good luck.

D
 
Yeah, I didn't have that kind of luck. The I1Pro was at 1.11.x.x already, and the I1V1 was at 1.10.x.x, so I really didn't have any choice about staying at 1.08.x.x.

I will do a firmware downgrade on the I1Pro and see where it is at. I will see about going straight to 1.8.1.00. I already have the firmware images. I also have the infamous 1.8.1.40 on hand as well if it won't downgrade with the DEBUG file.

Now that I have a funtioning X3 camera I can do the downgrades. I didn't want to risk the Z3 I have, as it was BNIB and was at the latest firmware already (July 2018 manufacture date, so well beyond the last update for the Z3), so I really don't want to risk anything more than the X3.

Actually, I have a better idea, I have a Osmo+ Z350 zoom camera on hand. I will use that to do the firmware rollbacks, that way it won't touch the cameras firmware at all. I can assume based on your own firmware revisions that the cameras can be (maybe *should be*) at the latest firmware revisions for them???

I will post back on how it all turns out. If I can get one of them to back-rev I will do the other. I just can't believe firmware updates are this dicey on a platform this old. You would have thought they would have fixed any "issues" back in 2017/2018 before the abandoned the platform.

Quick question, is there any reason to NOT use the latest DJI Go software on the tablets??? Or was it simply a matter that it was all based on the fact at the time of the 1.8.1.00 AC firmware and 1.6 RC firmware that was the correct version of the app? ie, they are all made to play nicely together so why add in a variable of an app that is newer to cause chaos?

Does this mean that every aircraft you have has a dedicated iPad for it? From a business perspective it makes sense. Just that for me, as of now, I am stuck using a few tablets/smartphones for a number of drones (Inspire 1, Mavic 2 Pro, Mavic 2 Zoom, Mavic Air 1, Phantom 4 Pro, Parrot Anafi), and even though for the P4Pro for example I have a fixed device (Samsung Galaxy Tab Pro 8.4) that has a fixed OS version, fixed older app to match the older firmware, I am REALLY liking the new Tripltek tablet I have for use with everything. I cannot see spending almost $700 a tablet for 6 tablets to have one for each drone, thus I am hoping that the latest revision of the tablet apps themselves are "acceptable". Again, I have not found any reference anywhere that states the latest apps are an issue, thus my inquiry.
 
Lastly, when you see a firmware version in the DJI Go "about" screen, when it has a "+" sign after the version, does that signify it was a factory load of that firmware revision??? (such as "1.8.1.0+" vs "1.8.1.0")
 
I may want to add, that when doing firmware updates, I notice that the log file (the one in the LOG directory) shows ALL the updates that have ever been run on that aircraft.

That being said, on the Inspire 1 V1, it shows everything from version 1.5.x.x all the way up to the 1.11.x.x update being done on it. Now, when I did the update to the Inspire 1 Pro, it showed only 3 updates. One was the "factory" 1.11.x.x update, then the 1.11.x.x update I did with the Osmo+ Z350 cam attached (trying to see if I could force a firmware update to the Osmo+ camera to get it to act like a Z3) which completed fine, and then it showed the update when I had the X5 camera installed and that one totally bombed with all these weird subsystem revisions and the X5 camera bricked.

After that episode, I put the Osmo+ camera back in and did the update with the X5 firmware (FC550) in DEBUG and it did the update just fine and the aircraft flies and works just fine as if nothing happened.

That is why I am wondering if the Z3 firmware had an older version of some modules compared to the X5 (or X3) firmwares it could have caused that issue where you can't rollback. If that is the case, maybe the anti-rollback is done with some sort of lock in to the cameras firmware, which means you risk bricking your cameras on a firmware rollback. Since the Inspire 1 won't update the Osmo+ camera firmware it is "safe" to use that to do firmware updates.

I also will mention that I find it totally strange that at time you need to retry firmware updates multiple times, almost like the Inspire 1 aircraft doesn't "boot properly" all the time. I wonder if there is some way to force a "clean boot". I would imagine there has to be, since I am sure the factory has to do it. Then again, I am sure the factory just plugs directly into each device and can interrogate and force firmware loads on whatever they want.
 
Yeah, I didn't have that kind of luck. The I1Pro was at 1.11.x.x already, and the I1V1 was at 1.10.x.x, so I really didn't have any choice about staying at 1.08.x.x.
Per the video I provided, I was able to successfully roll back from v1.10.xx BEFORE discovering the DEBUG file. Post-video I WAS able roll back to FW 1.08.xx. I just had to do it 1 FW at a time.




I will do a firmware downgrade on the I1Pro and see where it is at. I will see about going straight to 1.8.1.00. I already have the firmware images. I also have the infamous 1.8.1.40 on hand as well if it won't downgrade with the DEBUG file.
Good.



Now that I have a funtioning X3 camera I can do the downgrades. I didn't want to risk the Z3 I have, as it was BNIB and was at the latest firmware already (July 2018 manufacture date, so well beyond the last update for the Z3), so I really don't want to risk anything more than the X3.
I'm pretty sure the X3 camera FW must match the AC FW. So if your X3 doesn't world post-roll-back, that is why. Conversely, I was able to run several X5 cameras with varying Firmwares without a problem. Never update the X5. Ever.



Actually, I have a better idea, I have a Osmo+ Z350 zoom camera on hand. I will use that to do the firmware rollbacks, that way it won't touch the cameras firmware at all. I can assume based on your own firmware revisions that the cameras can be (maybe *should be*) at the latest firmware revisions for them???
No. Quite the opposite is true, especially for the X5. Upgrade the X5 and you will open Pandora's Box. I've successfully rolled back the X3, but not the X5. Never update the X5. Ever.




I will post back on how it all turns out. If I can get one of them to back-rev I will do the other. I just can't believe firmware updates are this dicey on a platform this old. You would have thought they would have fixed any "issues" back in 2017/2018 before the abandoned the platform.
Normally, yes. But Firmware roll-out is how the DJI Nazis bring down the FAA / FCC hammer. Of course, the release notes are devoid of glaring changes like decimating Tx power, invoking more NFZ restrictions and on and on. I'm sure DJI is well aware that if they were forthcoming with their release notes, nobody would update. Ever.




Quick question, is there any reason to NOT use the latest DJI Go software on the tablets???
Yes. DJI disables your drone until you take their test and/or login to the DJI mother ship via the updated Go App. The Go App will disable your drone at the worst possible time - like say out in the field on a job. Stay with Go App v3.1.1 and you will be golden. Allow it to do even the most minor update (to v3.1.12 for example), and you will be at their mercy in the field - forced to login, agree to new terms, take a test, yada, yada...



Or was it simply a matter that it was all based on the fact at the time of the 1.8.1.00 AC firmware and 1.6 RC firmware that was the correct version of the app? ie, they are all made to play nicely together so why add in a variable of an app that is newer to cause chaos?
No. As far as I know, the latest Go App will work with the legacy firmware with the aforementioned caveats.




Does this mean that every aircraft you have has a dedicated iPad for it?
Yes and no. My iPads are not toys. They are dedicated business tools and are treated as such. I use them for my drones, my sound company, monitoring my mother (via security cams), and most recently, I allowed Skype to install. That said, any iPad will work on any drone. This includes 5 iPads of varying flavors on 3 Inspires, 3 P4P's, a Mavic Pro and an M600 Pro. Go App v3.1.1 and Go4 App v4.0.8 are installed on all 5 iPads and NEVER allowed to update. In addition, all 5 iPads are locked down so they never update the iOS. This insures the legacy apps will continue to work on these platforms for the life of the iPads. As an added bonus, it also insures Apple won't throttle back my CPU's to leave me with the illusion of greater battery life.




From a business perspective it makes sense. Just that for me, as of now, I am stuck using a few tablets/smartphones for a number of drones (Inspire 1, Mavic 2 Pro, Mavic 2 Zoom, Mavic Air 1, Phantom 4 Pro, Parrot Anafi), and even though for the P4Pro for example I have a fixed device (Samsung Galaxy Tab Pro 8.4) that has a fixed OS version, fixed older app to match the older firmware,
As stated, all iPads work on all birds in any combination.



I am REALLY liking the new Tripltek tablet I have for use with everything.
Never heard of them. I have found Android devices to be not as reliable as the iPads. I'm no fanboy, but I can say with 100% confidence that the iPads have been rock-solid over the years, which is what I need.



I cannot see spending almost $700 a tablet for 6 tablets to have one for each drone,
Not necessary. All you need is 1 configured correctly. I just happen to have 3 (mostly for my sound company) that are all configured similarly. My business partner has 2.

Pro Tip: Don't allow any iPad to update past iOS 12.1.4. This is the latest version that can still be hacked via legacy iTunes.





thus I am hoping that the latest revision of the tablet apps themselves are "acceptable". Again, I have not found any reference anywhere that states the latest apps are an issue, thus my inquiry.
You can use the latest Go and Go4 App version. Just be prepared to be "Nazified" by DJI. I work in the field FAR away from WiFi AND Cell service. So I can't be randomly Nazified by the whims of DJI, as it could cost me jobs and clients. YMMV. And be aware that simply turning everything on while at home next to WiFi doesn't insure that you won't be randomly Nazified in the field a couple hours later. I was bitten by this ONCE when the Go App somehow, miraculously updated. A simple roll back of the app got me going. Fortunately, this was a lone job without a DP or client waiting for footage.

Good luck.

D
 
Last edited:
Well, at this point I am not willing to sacrifice a X3 camera (possibly) to a firmware downgrade, so the closest I could get was 1.09.01.30 (Z3 firmware).

Is it known that 1.08.1.00 is the only revision that has the video feed work properly, or is it anything less than 1.10.x.x???

If I remember in your video you mentioned that 1.10 was the death of video feed and 1.09.x.x had some NFZ updates that they had to fix?

As I type this it is loading the 1.09.01.30 firmware... I am just getting the beeping out of the ESC updates at this point.

I will respond when it is finished.
 
Well, at this point I am not willing to sacrifice a X3 camera (possibly) to a firmware downgrade, so the closest I could get was 1.09.01.30 (Z3 firmware).

Is it known that 1.08.1.00 is the only revision that has the video feed work properly, or is it anything less than 1.10.x.x???
The latter. Your v1.09.xx has "the good video feed." The only difference (noted in the release notes) is that v1.09.xx expanded NFZ's. So...if you're willing to deal with erroneous NFZ expansion, you should be able to stick with that version.




If I remember in your video you mentioned that 1.10 was the death of video feed and 1.09.x.x had some NFZ updates that they had to fix?
Correct. But I erred in that they EXPANDED the NFZ's in v1.09.xx.



As I type this it is loading the 1.09.01.30 firmware... I am just getting the beeping out of the ESC updates at this point.

I will respond when it is finished.
As I recall (it's been years), you need to let it cook for at least 40 minutes. Some guys reported that the roll back took over an hour.

Good luck.

D
 
Donnie, thanks for the clarification...

I can report, it was a complete success. Everything is rolled back to 1.09.01.30. I am in the process of doing the Inspire 1 V1 to the same.

Now that both are on that version I *could* go back to 1.08.01.00, but I also have found out about the firmware mods to, ahem, "fix" the NFZ so I might just go that route. You can also change the flight ceiling as well as forward/backward speeds, but I would imagine that the speed situation doesn't buy you much because you are limited by the battery charge anyways, so even if you get someplace faster you used the same amount of battery doing it.

Also, it only took about 25 minutes for the firmware downgrade to do its thing. I will report on how long the V1 takes.

I am in the process of downgrading the firmware on the controllers to 1.6 as well... They are truly annoying with all the **** beeping they do during the downgrade.
 
Last edited:
  • Like
Reactions: Donnie Frank
The Inspire 1 V1 also downgraded to 01.09.01.30 without issue. Only took about 20+ minutes. Actually seemed faster than the V2.

Now, I downgraded one of the GL658C controllers to 1.6, but upon restart it is showing a red light and constantly beeping. In the DJI Go status screen, under the top option it shows that there is new firmware versions, but it also shows a "controller encryption error". So I need to look into that a bit more before I start upgrading the rest of the controllers.

I wonder if I can do a "local upgrade", since I can get a hold of the older controller firmwares. My concern is that DJI hamstrung the firmware images inside the DJI Go app. I know they did for the NFZ updates they made for the Phantom 4 Pro and such (yeah, you can download older firmware, but they have the NFZ control stuff updated into the older firmware images you can download directly from DJI).
 
The Inspire 1 V1 also downgraded to 01.09.01.30 without issue. Only took about 20+ minutes. Actually seemed faster than the V2.

Now, I downgraded one of the GL658C controllers to 1.6, but upon restart it is showing a red light and constantly beeping. In the DJI Go status screen, under the top option it shows that there is new firmware versions, but it also shows a "controller encryption error". So I need to look into that a bit more before I start upgrading the rest of the controllers.

I wonder if I can do a "local upgrade", since I can get a hold of the older controller firmwares. My concern is that DJI hamstrung the firmware images inside the DJI Go app. I know they did for the NFZ updates they made for the Phantom 4 Pro and such (yeah, you can download older firmware, but they have the NFZ control stuff updated into the older firmware images you can download directly from DJI).
Try calibrating the joysticks. If this doesn't stop the red light, I would simply redo the controller roll back. You may have to let it upgrade first, then roll it back again. Other than the aforementioned annoying beep, this is a pretty painless process.

Good luck.

D
 
Yeah, I am rolling through version now on the controller. Recalibrating did nothing.

Which reminds me, I need to do the 32 channel mod when I install the older version... More reading to do...
 
Last edited:
OK, one really weird thing I have noticed is that on any device I have the latest version of DJI Go installed on (3.1.61), when I go to downgrade the controller it shows multiple 1.6.0 versions, as well as multiples of every version below 1.6.0.

I did load 3.1.1 on my Tripltek to work with the Inspire 1s and I noticed it will not allow firmware updates. As soon as I plug in the controller with version 1.7.80 on it, it doesn't detect it and doesn't show downgrade versions. So they must have changed something on the server side of things.

I am downgrading to 1.5.80 and will try again on the 3.1.1 app.

Well, 1.5.80 doesn't work with it either.

I am wondering if the GL658C revision controller needs a 1.7.xx version firmware??? - Edit: Answer is no, it does not. Seems like I have a funky controller since the other GL658C downgraded just fine to 1.6.0.
 
Last edited:
BTW, the Tripltek is an excellent android tablet. Vanilla Android 9 OS, 1200+ nits of display brightness, everything runs great and without hiccups. It has a 10,000mAh battery so it literally lasts for days while on and running. It is bright and visible during daylight in the sun outside.

Basically only the Crystal-Sky Ultra has more brightness.

Oh, it is also waterproof and crush-proof (you can actually run it over with a car and not destroy it).
 
  • Like
Reactions: Donnie Frank
Next chapter:

So, every other controller I have (two "A", a single "B" and a different "C") all downgraded to RC 1.6.0. I still cannot get the other "C" controller to downgrade beyond 1.7.40.

I have exhausted "the internet" in searching for an answer why. I have done resets on the controller, I have gone to every revision there is, hell, I even bricked the controller once because I chose to install DJI Go 3.1.58 on my Galaxy S9 to try to get it to upgrade properly (basically it would only show the mint-pale-green light with no other light, and a reset on the controller didn't work, plus it was seen as a P3 controller, so I ended up starting a P3 controller upgrade and then disconnected the USB when the light finally turned blue, which allowed it to be seen as an Inspire controller and allowed me to change the firmware).

I have tried every half-baked "fix" I came across, from going in and changing the mode and calibrations along with connecting to different aircrafts, etc, etc..

If anyone has any other ideas, I would love to hear them.

As it is, I don't think it will work in tandem with other 1.6.0 controllers either as a master or a slave, and I have found references where anything but 1.6.0 doesn't play nicely with the 1.8.x.x/1.9.x.x firmwares. Now, does that matter as a slave??? I have no idea. But, it would seem to be a waste of a "C" controller to use it as a slave. Plus it is known that "C" and "C" controllers should not be master/slaved because of interference.

Side-Note, in the logfile after the downgrade to 1.9.1.30 I did find it interested that where it does a compare between versions, it listed the firmware as:

[00008864]Packet vlink 01.09.0130 <-> 01.08.0100.

So if I am making proper interpretations, the actual "base firmware" is 01.08.0100 and the revision that layers on top is 01.09.0130. That would make sense if the only thing changed were NFZ database updates.

I will get the NFZ, elevation and speed mods done before I revert my Osmo+ camera back to it's latest firmware on the Osmo+ itself. I REALLY like the idea of not having to worry about bricking a camera doing firmware stuff.
 
Oh, one last thing, turns out that "A" and "B" controllers are passive in regards to dealing with heat. "C" controllers have built-in fans to cool the chipsets.

I wonder if that affects things positively or negatively for long-term use???
 
  • Like
Reactions: Donnie Frank

Members online

Forum statistics

Threads
22,315
Messages
210,835
Members
34,709
Latest member
honggeo