Topics

Wifi flash issues with latest master on Instein box


"Guilherme Vênere
 

Hello Howard

I'm testing the latest master with the changes you made to the flash procedure, but i'm not able to upload the Wifi sketch. The error indicates is below:

warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_open failed

My COM port is correct, and I can see it disappearing and reappearing in Device Manager when I turn the box off and on again with the switch in Wifi flash mode. 

It's not very clear to me from the changes you made what i have to do with the SERIAL_D_BAUD_DEFAULT variable, and whether we need to enable SERIAL_B_ESP_FLASHING in order for it to work, but i tried a few combinations of both and always get the same error.

Any suggestions?

Guilherme


Howard Dutton
 

I was changing the design around a bit so might have been broken at the moment you downloaded.  I finally settled on putting ESP8266 flashing in a class, nicer & smaller code.

See if this works, if not I'll take a look over it again.  You do not need to use SERIAL_B_ESP_FLASHING, if the AddonTriggerPin exists in the pinmap it'll enable flashing using it.

On a MaxPCB3 SERIAL_B_ESP_FLASHING works fine.


Howard Dutton
 
Edited

On Tue, Oct 20, 2020 at 10:37 AM, "Guilherme Vênere wrote:
It's not very clear to me from the changes you made what i have to do with the SERIAL_D_BAUD_DEFAULT variable,
SERIAL_D_BAUD_DEFAULT is now omitted from Config.h.  For your pinmap it defaults (in the HAL) to 9600.  If you add the #define in Config.h it'll override the HAL use whatever you set it to.


"Guilherme Vênere
 

Hi Howard

Tested with the latest master and it works now! I tested the SHC too and everything seems to be working fine, thanks again for the awesome work! I will work with the other OnStep user who contacted me to see if he can get his box updated too, and report back any issues. I guess we have a solution for OnStep users now? :)

Guilherme

On Tue, Oct 20, 2020 at 11:34 AM Howard Dutton <hjd1964@...> wrote:
On Tue, Oct 20, 2020 at 10:37 AM, "Guilherme Vênere wrote:
It's not very clear to me from the changes you made what i have to do with the SERIAL_D_BAUD_DEFAULT variable,
SERIAL_D_BAUD_DEFAULT is now omitted from Config.h.  For your pinmap it defualts (in the HAL) to 9600.  If you add the #define in Config.h it'll override the HAL use whatever you set it to.


Khalid Baheyeldin
 

On Tue, Oct 20, 2020 at 02:40 PM, "Guilherme Vênere wrote:
Tested with the latest master and it works now! I tested the SHC too and everything seems to be working fine, thanks again for the awesome work! I will work with the other OnStep user who contacted me to see if he can get his box updated too, and report back any issues. I guess we have a solution for OnStep users now? :)
Guilherme,

Thank you for taking the time to get the Instein controller working with OnStep 4.x.

This is for the ESP32 based controller, not the Arduino one.

Howard, it would be a good idea to have a entry on the Wiki for that controller.
It does not have to be comprehensive: only what Config.h changes are needed specifically for the Instein controller.

Then we can point people to it when they ask.


Howard Dutton
 

On Tue, Oct 20, 2020 at 11:58 AM, Khalid Baheyeldin wrote:
Howard, it would be a good idea to have a entry on the Wiki for that controller.
While I don't mind helping users with generic changes to OnStep that bend it a little to support this commercial hardware, I'm against adding a Wiki page (thus promoting it) or spending much of my time on it.


Khalid Baheyeldin
 

On Tue, Oct 20, 2020 at 03:48 PM, Howard Dutton wrote:
On Tue, Oct 20, 2020 at 11:58 AM, Khalid Baheyeldin wrote:
Howard, it would be a good idea to have a entry on the Wiki for that controller.
While I don't mind helping users with generic changes to OnStep that bend it a little to support this commercial hardware, I'm against adding a Wiki page (thus promoting it) or spending much of my time on it.
My idea was not about that at all.
My motivation is to reduce the amount of time and effort answering questions on the list, which happen because of delays in support, slow communication, or whatever reason.

Right now, only you and Guilherme know how to configure OnStep for that hardware.
If this is briefly described somewhere, then we tell people "here is a page on what we know, and how you can do it".
So we end up spending less time supporting a commercial platform, not more.


"Guilherme Vênere
 

I don't mind helping new users if/when they need help here, and i will have to keep this information somewhere for my own use anyway, so I guess I can have a readme/example config in my fork which won't be merged to master and we can point users to this document instead when someone asks.

Does that work?

Guilherme


On Tue, Oct 20, 2020 at 12:55 PM Khalid Baheyeldin <kbahey@...> wrote:
On Tue, Oct 20, 2020 at 03:48 PM, Howard Dutton wrote:
On Tue, Oct 20, 2020 at 11:58 AM, Khalid Baheyeldin wrote:
Howard, it would be a good idea to have a entry on the Wiki for that controller.
While I don't mind helping users with generic changes to OnStep that bend it a little to support this commercial hardware, I'm against adding a Wiki page (thus promoting it) or spending much of my time on it.
My idea was not about that at all.
My motivation is to reduce the amount of time and effort answering questions on the list, which happen because of delays in support, slow communication, or whatever reason.

Right now, only you and Guilherme know how to configure OnStep for that hardware.
If this is briefly described somewhere, then we tell people "here is a page on what we know, and how you can do it".
So we end up spending less time supporting a commercial platform, not more.


Howard Dutton
 

On Tue, Oct 20, 2020 at 12:59 PM, "Guilherme Vênere wrote:
Does that work?
That's fine with me.


Dave Schwartz
 

Agree with Howard, disagree with Khalid.

Instein has taken a branch and made a commercial product out of it that has departed from the OnStep roadmap. Nothing wrong with that but its up to them to support their customers, not us. If they are listening and conscious, they will recognize what a great favor has been done for them and set about documenting this on their own web pages if they think this is a good thing for their customers. Not up to us to make that decision.

On 2020-10-20 3:55 p.m., Khalid Baheyeldin wrote:
On Tue, Oct 20, 2020 at 03:48 PM, Howard Dutton wrote:

On Tue, Oct 20, 2020 at 11:58 AM, Khalid Baheyeldin wrote:

Howard, it would be a good idea to have a entry on the Wiki
for that controller.

While I don't mind helping users with generic changes to OnStep
that bend it a little to support this commercial hardware, I'm
against adding a Wiki page (thus promoting it) or spending much of
my time on it.

My idea was not about that at all.
My motivation is to reduce the amount of time and effort answering questions on the list, which happen because of delays in support, slow communication, or whatever reason.

Right now, only you and Guilherme know how to configure OnStep for that hardware.
If this is briefly described somewhere, then we tell people "here is a page on what we know, and how you can do it".
So we end up spending less time supporting a commercial platform, not more.


Khalid Baheyeldin
 

The questions will come regardless, as we have seen.
Having a place to point people to will help reduce the support time and effort.

How about a FAQ item then about Instein, saying they are different, and need so and so in Config.h, very briefly?
Who can write that?


Dave Schwartz
 

Still opposed to anything other than the WiFi having a pointer to the Instein site and saying that it may be possible to update some Instein controllers to the master but the details (that may change) are strictly the responsibility of Instein to document and maintain.

There may be group members who will keep it compatible out of good will (and Howard should absolutely not be concerned about doing so) but it cannot be guaranteed. If he really knows what's good for him, he will maintain compatibility and push changes himself. However, he may have some other agenda where he wants to be in control of the software load for his product to reduce the spectrum of support issues it may generate.

On 2020-10-21 11:13 a.m., Khalid Baheyeldin wrote:
The questions will come regardless, as we have seen.
Having a place to point people to will help reduce the support time and effort.

How about a FAQ item then about Instein, saying they are different, and need so and so in Config.h, very briefly?
Who can write that?


Dave Schwartz
 

Sorry... Wiki, not WiFi.

On 2020-10-21 11:36 a.m., Dave Schwartz wrote:
Still opposed to anything other than the WiFi having a pointer to the Instein site and saying that it may be possible to update some Instein controllers to the master but the details (that may change) are strictly the responsibility of Instein to document and maintain.

There may be group members who will keep it compatible out of good will (and Howard should absolutely not be concerned about doing so) but it cannot be guaranteed. If he really knows what's good for him, he will maintain compatibility and push changes himself. However, he may have some other agenda where he wants to be in control of the software load for his product to reduce the spectrum of support issues it may generate.

On 2020-10-21 11:13 a.m., Khalid Baheyeldin wrote:
The questions will come regardless, as we have seen.
Having a place to point people to will help reduce the support time and effort.

How about a FAQ item then about Instein, saying they are different, and need so and so in Config.h, very briefly?
Who can write that?



Khalid Baheyeldin
 

Why did Howard merge Guilherme's Instein fork in OnStep then?
What use is that to someone using Instein, if there is nothing on it anywhere?

I am fine with the brief documentation of Instein being in Guilherme's github wiki for example, and we link to it (as well as Instein's site). We just need a URL that we can point people to where they can get the answer. 


Howard Dutton
 

On Wed, Oct 21, 2020 at 08:36 AM, Dave Schwartz wrote:
product to reduce the spectrum of support issues it may generate.
Lol, yea kicking them here instead.


Khalid Baheyeldin
 

On Wed, Oct 21, 2020 at 02:00 PM, Howard Dutton wrote:
On Wed, Oct 21, 2020 at 08:36 AM, Dave Schwartz wrote:
product to reduce the spectrum of support issues it may generate.
Lol, yea kicking them here instead.
We don't need to document everything about Instein controllers.
Definitely no need for a full blown board page.

All we need to document is what Guilhereme's fork had, and that is now part of the standard OnStep.
Specifically: highlight the configuration differences from other 'standard' community boards (e.g. RX/TX serial).
And that is about as far as we should go.
Even a FAQ question with a link to where Guilherme documents that is sufficient.


Howard Dutton
 

On Wed, Oct 21, 2020 at 11:06 AM, Khalid Baheyeldin wrote:
We don't need to document everything about Instein controllers.
I'm not changing my mind on this.


Howard Dutton
 

On Wed, Oct 21, 2020 at 11:08 AM, Howard Dutton wrote:
On Wed, Oct 21, 2020 at 11:06 AM, Khalid Baheyeldin wrote:
We don't need to document everything about Instein controllers.
I'm not changing my mind on this.
It's a commercial product, Instein can take care of it.


Howard Dutton
 

On Wed, Oct 21, 2020 at 11:10 AM, Howard Dutton wrote:
On Wed, Oct 21, 2020 at 11:08 AM, Howard Dutton wrote:
On Wed, Oct 21, 2020 at 11:06 AM, Khalid Baheyeldin wrote:
We don't need to document everything about Instein controllers.
I'm not changing my mind on this.
It's a commercial product, Instein can take care of it
Thinking back to Charles Lemaire's licensing regrets and I understand where he's coming from sometimes.


"Guilherme Vênere
 

Hi

Like I said, I don't mind keeping this documentation in my Github. I understand the concern in putting this information on the official Wiki, and just to make sure it's said here, I have no connection to Instein at all besides being an owner of one of his boxes who got stranded without support like others. 

But as a user I also don't want to be locked out to outdated software and unable to make simple changes to the config. In my case the box came configured to Southern Hemisphere, and it took me a month to get access to the source code after I got the box. Luckily (i guess) i live in Oregon which was covered in smoke at the time so not much was lost. And from what i see here in the group other users have similar problems and having this option to use the official master branch is a huge help. 

So i want to thank Howard for merging the changes to master, and i will keep the example config and instructions on my Github, this way if someone comes asking here again we can just point them there. I guess it won't make much difference adding this to Wiki because we know people usually don't read docs before asking so the questions would still come :)

I'm working with another member here on setting up his GM8 with Instein, and will document the process and upload this to my repo. I'll send a link later

Guilherme


On Wed, Oct 21, 2020 at 11:13 AM Howard Dutton <hjd1964@...> wrote:
On Wed, Oct 21, 2020 at 11:10 AM, Howard Dutton wrote:
On Wed, Oct 21, 2020 at 11:08 AM, Howard Dutton wrote:
On Wed, Oct 21, 2020 at 11:06 AM, Khalid Baheyeldin wrote:
We don't need to document everything about Instein controllers.
I'm not changing my mind on this.
It's a commercial product, Instein can take care of it
Thinking back to Charles Lemaire's licensing regrets and I understand where he's coming from sometimes.