Hi Mark, The 3.1 module arrived in today's mail. I haven't plugged it in yet, but two "unboxing" observations... The unit looks really nice, though it seems that the top shell is a tad too wide and overlaps the bottom piece by nearly a mm on one corner. And, not evenly, at that; it's like the corner by the Vehicle connector got stretched a bit outward (or the other half pushed inward). The other two sides are all pretty evenly matched. The 3.0 proto unit was not like this. {shrug} Also, the two SMA dust caps seemed to have had some reaction with the adhesive on the flap of the padded envelope. They were stuck to the flap, pulled away from the connectors (so, not much dust protection), and the adhesive on the flap seemed to be very gooey in that area. The caps seemed to have been more or less unaffected, so it's more of a cosmetic issue. Perhaps they could point the module in the other direction (SMA end first), to prevent this in the future? My intent is to play "customer" with this unit, only using officially released code, updated through typical methods (i.e. not via the developer's kit) unless I need to do otherwise. I've got some short-term distractions through the weekend, but will take it out for a spin next week. Greg
Got mine as well, without customs hassle. My dust caps were in place and OK. The top shell also is a bit wider than the bottom, but nowhere near 1 mm, more like 0.2 - 0.3. Regards, Michael Am 14.04.2018 um 00:49 schrieb Greg D.:
Hi Mark,
The 3.1 module arrived in today's mail. I haven't plugged it in yet, but two "unboxing" observations...
The unit looks really nice, though it seems that the top shell is a tad too wide and overlaps the bottom piece by nearly a mm on one corner. And, not evenly, at that; it's like the corner by the Vehicle connector got stretched a bit outward (or the other half pushed inward). The other two sides are all pretty evenly matched. The 3.0 proto unit was not like this. {shrug}
Also, the two SMA dust caps seemed to have had some reaction with the adhesive on the flap of the padded envelope. They were stuck to the flap, pulled away from the connectors (so, not much dust protection), and the adhesive on the flap seemed to be very gooey in that area. The caps seemed to have been more or less unaffected, so it's more of a cosmetic issue. Perhaps they could point the module in the other direction (SMA end first), to prevent this in the future?
My intent is to play "customer" with this unit, only using officially released code, updated through typical methods (i.e. not via the developer's kit) unless I need to do otherwise. I've got some short-term distractions through the weekend, but will take it out for a spin next week.
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hard to measure the overhang... Here's what it looks like. I think the dust cap issue depends on how the sealing flap is closed over the module, i.e. whether the sticky part is fully attached to the body of the envelope, or whether it's done loosely, leaving a bit of the adhesive exposed to the contents. I got "lucky" in that regard :(. Greg Michael Balzer wrote:
Got mine as well, without customs hassle.
My dust caps were in place and OK. The top shell also is a bit wider than the bottom, but nowhere near 1 mm, more like 0.2 - 0.3.
Regards, Michael
Am 14.04.2018 um 00:49 schrieb Greg D.:
Hi Mark,
The 3.1 module arrived in today's mail. I haven't plugged it in yet, but two "unboxing" observations...
The unit looks really nice, though it seems that the top shell is a tad too wide and overlaps the bottom piece by nearly a mm on one corner. And, not evenly, at that; it's like the corner by the Vehicle connector got stretched a bit outward (or the other half pushed inward). The other two sides are all pretty evenly matched. The 3.0 proto unit was not like this. {shrug}
Also, the two SMA dust caps seemed to have had some reaction with the adhesive on the flap of the padded envelope. They were stuck to the flap, pulled away from the connectors (so, not much dust protection), and the adhesive on the flap seemed to be very gooey in that area. The caps seemed to have been more or less unaffected, so it's more of a cosmetic issue. Perhaps they could point the module in the other direction (SMA end first), to prevent this in the future?
My intent is to play "customer" with this unit, only using officially released code, updated through typical methods (i.e. not via the developer's kit) unless I need to do otherwise. I've got some short-term distractions through the weekend, but will take it out for a spin next week.
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Greg, That is nasty. It must be a manufacturing defect, as I haven’t seen anything like that on other cases (and I’ve seen about 25 of them). I’ll send you another case in the mail, when I next go to the post office. Regards, Mark.
On 15 Apr 2018, at 3:14 AM, Greg D. <gregd2350@gmail.com> wrote:
Hard to measure the overhang... Here's what it looks like.
I think the dust cap issue depends on how the sealing flap is closed over the module, i.e. whether the sticky part is fully attached to the body of the envelope, or whether it's done loosely, leaving a bit of the adhesive exposed to the contents. I got "lucky" in that regard :(.
Greg
Michael Balzer wrote:
Got mine as well, without customs hassle.
My dust caps were in place and OK. The top shell also is a bit wider than the bottom, but nowhere near 1 mm, more like 0.2 - 0.3.
Regards, Michael
Am 14.04.2018 um 00:49 schrieb Greg D.:
Hi Mark,
The 3.1 module arrived in today's mail. I haven't plugged it in yet, but two "unboxing" observations...
The unit looks really nice, though it seems that the top shell is a tad too wide and overlaps the bottom piece by nearly a mm on one corner. And, not evenly, at that; it's like the corner by the Vehicle connector got stretched a bit outward (or the other half pushed inward). The other two sides are all pretty evenly matched. The 3.0 proto unit was not like this. {shrug}
Also, the two SMA dust caps seemed to have had some reaction with the adhesive on the flap of the padded envelope. They were stuck to the flap, pulled away from the connectors (so, not much dust protection), and the adhesive on the flap seemed to be very gooey in that area. The caps seemed to have been more or less unaffected, so it's more of a cosmetic issue. Perhaps they could point the module in the other direction (SMA end first), to prevent this in the future?
My intent is to play "customer" with this unit, only using officially released code, updated through typical methods (i.e. not via the developer's kit) unless I need to do otherwise. I've got some short-term distractions through the weekend, but will take it out for a spin next week.
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
<IMG_20180414_120111.jpg>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Hi Mark, It's totally cosmetic, and the unit will be under the dash in the car, so nobody else will see it (or if they do, I'll call it a proto unit :) ). Unless you want this one back, I am fine with keeping it. Just thought you should know about it. Greg Mark Webb-Johnson wrote:
Greg,
That is nasty. It must be a manufacturing defect, as I haven’t seen anything like that on other cases (and I’ve seen about 25 of them).
I’ll send you another case in the mail, when I next go to the post office.
Regards, Mark.
On 15 Apr 2018, at 3:14 AM, Greg D. <gregd2350@gmail.com> wrote:
Hard to measure the overhang... Here's what it looks like.
I think the dust cap issue depends on how the sealing flap is closed over the module, i.e. whether the sticky part is fully attached to the body of the envelope, or whether it's done loosely, leaving a bit of the adhesive exposed to the contents. I got "lucky" in that regard :(.
Greg
Michael Balzer wrote:
Got mine as well, without customs hassle.
My dust caps were in place and OK. The top shell also is a bit wider than the bottom, but nowhere near 1 mm, more like 0.2 - 0.3.
Regards, Michael
Am 14.04.2018 um 00:49 schrieb Greg D.:
Hi Mark,
The 3.1 module arrived in today's mail. I haven't plugged it in yet, but two "unboxing" observations...
The unit looks really nice, though it seems that the top shell is a tad too wide and overlaps the bottom piece by nearly a mm on one corner. And, not evenly, at that; it's like the corner by the Vehicle connector got stretched a bit outward (or the other half pushed inward). The other two sides are all pretty evenly matched. The 3.0 proto unit was not like this. {shrug}
Also, the two SMA dust caps seemed to have had some reaction with the adhesive on the flap of the padded envelope. They were stuck to the flap, pulled away from the connectors (so, not much dust protection), and the adhesive on the flap seemed to be very gooey in that area. The caps seemed to have been more or less unaffected, so it's more of a cosmetic issue. Perhaps they could point the module in the other direction (SMA end first), to prevent this in the future?
My intent is to play "customer" with this unit, only using officially released code, updated through typical methods (i.e. not via the developer's kit) unless I need to do otherwise. I've got some short-term distractions through the weekend, but will take it out for a spin next week.
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev <IMG_20180414_120111.jpg>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
That makes more sense. Glad to hear all good now. Regards, Mark.
On 16 Apr 2018, at 11:50 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
An update!! So, I thought I'd open up the unit and see what was going on with the case by itself. The moment I released one of the screws, there was a snap! and the side popped into place. It is now in perfect alignment.
I don't remember which screw it was, but it seems that the PC board wasn't seated properly when the case was assembled.
So, not a defect in the material, but rather in the assembly process.
Greg
Greg D. wrote:
Hi Mark,
It's totally cosmetic, and the unit will be under the dash in the car, so nobody else will see it (or if they do, I'll call it a proto unit :) ). Unless you want this one back, I am fine with keeping it. Just thought you should know about it.
Greg
Mark Webb-Johnson wrote:
Greg,
That is nasty. It must be a manufacturing defect, as I haven’t seen anything like that on other cases (and I’ve seen about 25 of them).
I’ll send you another case in the mail, when I next go to the post office.
Regards, Mark.
On 15 Apr 2018, at 3:14 AM, Greg D. <gregd2350@gmail.com> <mailto:gregd2350@gmail.com> wrote:
Hard to measure the overhang... Here's what it looks like.
I think the dust cap issue depends on how the sealing flap is closed over the module, i.e. whether the sticky part is fully attached to the body of the envelope, or whether it's done loosely, leaving a bit of the adhesive exposed to the contents. I got "lucky" in that regard :(.
Greg
Michael Balzer wrote:
Got mine as well, without customs hassle.
My dust caps were in place and OK. The top shell also is a bit wider than the bottom, but nowhere near 1 mm, more like 0.2 - 0.3.
Regards, Michael
Am 14.04.2018 um 00:49 schrieb Greg D.:
Hi Mark,
The 3.1 module arrived in today's mail. I haven't plugged it in yet, but two "unboxing" observations...
The unit looks really nice, though it seems that the top shell is a tad too wide and overlaps the bottom piece by nearly a mm on one corner. And, not evenly, at that; it's like the corner by the Vehicle connector got stretched a bit outward (or the other half pushed inward). The other two sides are all pretty evenly matched. The 3.0 proto unit was not like this. {shrug}
Also, the two SMA dust caps seemed to have had some reaction with the adhesive on the flap of the padded envelope. They were stuck to the flap, pulled away from the connectors (so, not much dust protection), and the adhesive on the flap seemed to be very gooey in that area. The caps seemed to have been more or less unaffected, so it's more of a cosmetic issue. Perhaps they could point the module in the other direction (SMA end first), to prevent this in the future?
My intent is to play "customer" with this unit, only using officially released code, updated through typical methods (i.e. not via the developer's kit) unless I need to do otherwise. I've got some short-term distractions through the weekend, but will take it out for a spin next week.
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> <IMG_20180414_120111.jpg>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Hi OVMS v3 devs, In preparation of receiveing the module, i'm trying to compile what's currently on github. But while doing so, i'm running into problems I did the following: Install the toolchain (windows) cd ~/esp git clone --recursive https://github.com/openvehicles/esp-idf.git cd .. git clone https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3.git then in the /components/mongoose/ folder did: git clone https://github.com/openvehicles/mongoose.git It now does compile up to the following error message: In file included from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.h:34:0, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_peripherals.h:67, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32can/src/esp32can.cpp:42: C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:63:5: error: 'ppp_pcb' does not name a type ppp_pcb* m_ppp; ^ C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:64:18: error: field 'm_ppp_netif' has incomplete type 'netif' struct netif m_ppp_netif; ^ Any idea what i'm missing? -Mike
Mike, Separately cloning mongoose is not the usual procedure. Normally it is just "git submodule update" after cloning OVMS. That is not an explanation for the compilation error you encountered, though. Something else is missing. -- Steve On Fri, 20 Apr 2018, Michael Stegen wrote:
Hi OVMS v3 devs,
In preparation of receiveing the module, i'm trying to compile what's currently on github. But while doing so, i'm running into problems
I did the following: Install the toolchain (windows)
cd ~/esp git clone --recursive https://github.com/openvehicles/esp-idf.git cd .. git clone https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3.git then in the /components/mongoose/ folder did: git clone https://github.com/openvehicles/mongoose.git
It now does compile up to the following error message:
In file included from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.h:34:0, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_peripherals.h:67, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32can/src/esp32can.cpp:42: C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:63:5: error: 'ppp_pcb' does not name a type ppp_pcb* m_ppp; ^ C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:64:18: error: field 'm_ppp_netif' has incomplete type 'netif' struct netif m_ppp_netif; ^
Any idea what i'm missing?
-Mike
Steve, Thanks for your suggestion. I tried it ( git submodule update --init) and it did install mongoose in the correct folder. However, as you already noticed, this was not the solution to the problem. Exact same error also happens on a Ubuntu 16.04 installation i did. I'm clearly missing something... but what? -Mike Op 21-4-2018 om 8:43 schreef Stephen Casner:
Mike,
Separately cloning mongoose is not the usual procedure. Normally it is just "git submodule update" after cloning OVMS. That is not an explanation for the compilation error you encountered, though. Something else is missing.
-- Steve
On Fri, 20 Apr 2018, Michael Stegen wrote:
Hi OVMS v3 devs,
In preparation of receiveing the module, i'm trying to compile what's currently on github. But while doing so, i'm running into problems
I did the following: Install the toolchain (windows)
cd ~/esp git clone --recursive https://github.com/openvehicles/esp-idf.git cd .. git clone https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3.git then in the /components/mongoose/ folder did: git clone https://github.com/openvehicles/mongoose.git
It now does compile up to the following error message:
In file included from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.h:34:0, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_peripherals.h:67, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32can/src/esp32can.cpp:42: C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:63:5: error: 'ppp_pcb' does not name a type ppp_pcb* m_ppp; ^ C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:64:18: error: field 'm_ppp_netif' has incomplete type 'netif' struct netif m_ppp_netif; ^
Any idea what i'm missing?
-Mike
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- NEW address as of 3-3-2018 Stegen Electronics Westeinde 15 1606 CZ Venhuizen The Netherlands Tel: +31 228-851219 Tel: +31 10-5016960 www.stegen.com
Can you try copy support/sdkconfig.default.hw31 to sdkconfig to give a standard set of defaults (those used for production). You will then need to adjust the UART path appropriately. Also, please ‘git pull’ on each of the projects, to make sure you have the latest sources. Regards, Mark.
On 21 Apr 2018, at 10:30 PM, Michael Stegen <michael@stegen.com> wrote:
Steve,
Thanks for your suggestion. I tried it ( git submodule update --init) and it did install mongoose in the correct folder.
However, as you already noticed, this was not the solution to the problem.
Exact same error also happens on a Ubuntu 16.04 installation i did. I'm clearly missing something... but what?
-Mike
Op 21-4-2018 om 8:43 schreef Stephen Casner:
Mike,
Separately cloning mongoose is not the usual procedure. Normally it is just "git submodule update" after cloning OVMS. That is not an explanation for the compilation error you encountered, though. Something else is missing.
-- Steve
On Fri, 20 Apr 2018, Michael Stegen wrote:
Hi OVMS v3 devs,
In preparation of receiveing the module, i'm trying to compile what's currently on github. But while doing so, i'm running into problems
I did the following: Install the toolchain (windows)
cd ~/esp git clone --recursive https://github.com/openvehicles/esp-idf.git cd .. git clone https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3.git then in the /components/mongoose/ folder did: git clone https://github.com/openvehicles/mongoose.git
It now does compile up to the following error message:
In file included from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.h:34:0, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_peripherals.h:67, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32can/src/esp32can.cpp:42: C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:63:5: error: 'ppp_pcb' does not name a type ppp_pcb* m_ppp; ^ C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:64:18: error: field 'm_ppp_netif' has incomplete type 'netif' struct netif m_ppp_netif; ^
Any idea what i'm missing?
-Mike
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
NEW address as of 3-3-2018
Stegen Electronics Westeinde 15 1606 CZ Venhuizen The Netherlands
Tel: +31 228-851219 Tel: +31 10-5016960 www.stegen.com
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Mark, Copying support/sdkconfig.default.hw31 to sdkconfig fixed the issue, thanks! -Mike Op 21-4-2018 om 16:46 schreef Mark Webb-Johnson:
Can you try copy support/sdkconfig.default.hw31 to sdkconfig to give a standard set of defaults (those used for production). You will then need to adjust the UART path appropriately.
Also, please ‘git pull’ on each of the projects, to make sure you have the latest sources.
Regards, Mark.
On 21 Apr 2018, at 10:30 PM, Michael Stegen <michael@stegen.com> wrote:
Steve,
Thanks for your suggestion. I tried it ( git submodule update --init) and it did install mongoose in the correct folder.
However, as you already noticed, this was not the solution to the problem.
Exact same error also happens on a Ubuntu 16.04 installation i did. I'm clearly missing something... but what?
-Mike
Op 21-4-2018 om 8:43 schreef Stephen Casner:
Mike,
Separately cloning mongoose is not the usual procedure. Normally it is just "git submodule update" after cloning OVMS. That is not an explanation for the compilation error you encountered, though. Something else is missing.
-- Steve
On Fri, 20 Apr 2018, Michael Stegen wrote:
Hi OVMS v3 devs,
In preparation of receiveing the module, i'm trying to compile what's currently on github. But while doing so, i'm running into problems
I did the following: Install the toolchain (windows)
cd ~/esp git clone --recursive https://github.com/openvehicles/esp-idf.git cd .. git clone https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3.git then in the /components/mongoose/ folder did: git clone https://github.com/openvehicles/mongoose.git
It now does compile up to the following error message:
In file included from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.h:34:0, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_peripherals.h:67, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32can/src/esp32can.cpp:42: C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:63:5: error: 'ppp_pcb' does not name a type ppp_pcb* m_ppp; ^ C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:64:18: error: field 'm_ppp_netif' has incomplete type 'netif' struct netif m_ppp_netif; ^
Any idea what i'm missing?
-Mike
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Michael, Do you still have the old sdkconfig around? If so, please do a ‘diff -u support/sdkconfig.default.hw31 sdkconfig’ so we can see what is different. Regards, Mark
On 22 Apr 2018, at 4:44 PM, Michael Stegen <michael@stegen.com> wrote:
Mark,
Copying support/sdkconfig.default.hw31 to sdkconfig fixed the issue, thanks!
-Mike
Op 21-4-2018 om 16:46 schreef Mark Webb-Johnson:
Can you try copy support/sdkconfig.default.hw31 to sdkconfig to give a standard set of defaults (those used for production). You will then need to adjust the UART path appropriately.
Also, please ‘git pull’ on each of the projects, to make sure you have the latest sources.
Regards, Mark.
On 21 Apr 2018, at 10:30 PM, Michael Stegen <michael@stegen.com> wrote:
Steve,
Thanks for your suggestion. I tried it ( git submodule update --init) and it did install mongoose in the correct folder.
However, as you already noticed, this was not the solution to the problem.
Exact same error also happens on a Ubuntu 16.04 installation i did. I'm clearly missing something... but what?
-Mike
Op 21-4-2018 om 8:43 schreef Stephen Casner:
Mike,
Separately cloning mongoose is not the usual procedure. Normally it is just "git submodule update" after cloning OVMS. That is not an explanation for the compilation error you encountered, though. Something else is missing.
-- Steve
On Fri, 20 Apr 2018, Michael Stegen wrote:
Hi OVMS v3 devs,
In preparation of receiveing the module, i'm trying to compile what's currently on github. But while doing so, i'm running into problems
I did the following: Install the toolchain (windows)
cd ~/esp git clone --recursive https://github.com/openvehicles/esp-idf.git cd .. git clone https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3.git then in the /components/mongoose/ folder did: git clone https://github.com/openvehicles/mongoose.git
It now does compile up to the following error message:
In file included from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.h:34:0, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_peripherals.h:67, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32can/src/esp32can.cpp:42: C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:63:5: error: 'ppp_pcb' does not name a type ppp_pcb* m_ppp; ^ C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:64:18: error: field 'm_ppp_netif' has incomplete type 'netif' struct netif m_ppp_netif; ^
Any idea what i'm missing?
-Mike
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Hi Mark, Also having the same issues here, if you follow the instructions,the 2.1 branch doesn't contain components/heap, have switched to master branch, however support/sdkconfig.default.hw31 seems to be missing a lot of configuration, get asked lots of questions, such as: 'make' warns on undefined variables (MAKE_WARN_UNDEFINED_VARIABLES) [Y/n/?] (NEW) * * Bootloader config * Bootloader log verbosity 1. No output (LOG_BOOTLOADER_LEVEL_NONE) 2. Error (LOG_BOOTLOADER_LEVEL_ERROR)
3. Warning (LOG_BOOTLOADER_LEVEL_WARN)
4. Info (LOG_BOOTLOADER_LEVEL_INFO) 5. Debug (LOG_BOOTLOADER_LEVEL_DEBUG) 6. Verbose (LOG_BOOTLOADER_LEVEL_VERBOSE) choice[1-6?]: 3 SPI Flash WP Pin when customising pins via efuse (read help) (BOOTLOADER_SPI_WP_PIN) [7] (NEW) VDDSDIO LDO voltage 1. 1.8V (BOOTLOADER_VDDSDIO_BOOST_1_8V) (NEW)
2. 1.9V (BOOTLOADER_VDDSDIO_BOOST_1_9V) (NEW)
choice[1-2?]: I've tried to answer as many as I believe are to be correct, however I guess the question is, is the master branch correct for esp-idf and does anyone have a sdkconfig that has all the correct answers for this version? Thanks Fran On 23 April 2018 at 01:33, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Michael,
Do you still have the old sdkconfig around? If so, please do a ‘diff -u support/sdkconfig.default.hw31 sdkconfig’ so we can see what is different.
Regards, Mark
On 22 Apr 2018, at 4:44 PM, Michael Stegen <michael@stegen.com> wrote:
Mark,
Copying support/sdkconfig.default.hw31 to sdkconfig fixed the issue, thanks!
-Mike
Op 21-4-2018 om 16:46 schreef Mark Webb-Johnson:
Can you try copy support/sdkconfig.default.hw31 to sdkconfig to give a standard set of defaults (those used for production). You will then need to adjust the UART path appropriately.
Also, please ‘git pull’ on each of the projects, to make sure you have the latest sources.
Regards, Mark.
On 21 Apr 2018, at 10:30 PM, Michael Stegen <michael@stegen.com> wrote:
Steve,
Thanks for your suggestion. I tried it ( git submodule update --init) and it did install mongoose in the correct folder.
However, as you already noticed, this was not the solution to the problem.
Exact same error also happens on a Ubuntu 16.04 installation i did. I'm clearly missing something... but what?
-Mike
Op 21-4-2018 om 8:43 schreef Stephen Casner:
Mike,
Separately cloning mongoose is not the usual procedure. Normally it is just "git submodule update" after cloning OVMS. That is not an explanation for the compilation error you encountered, though. Something else is missing.
-- Steve
On Fri, 20 Apr 2018, Michael Stegen wrote:
Hi OVMS v3 devs,
In preparation of receiveing the module, i'm trying to compile what's currently on github. But while doing so, i'm running into problems
I did the following: Install the toolchain (windows)
cd ~/esp git clone --recursive https://github.com/openvehicles/esp-idf.git cd .. git clone https://github.com/openvehicles/Open-Vehicle- Monitoring-System-3.git then in the /components/mongoose/ folder did: git clone https://github.com/openvehicles/mongoose.git
It now does compile up to the following error message:
In file included from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/ vehicle/OVMS.V3/components/simcom/src/simcom.h:34:0, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/ vehicle/OVMS.V3/main/ovms_peripherals.h:67, from C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/ vehicle/OVMS.V3/components/esp32can/src/esp32can.cpp:42: C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/ vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:63:5: error: 'ppp_pcb' does not name a type ppp_pcb* m_ppp; ^ C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/ vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:64:18: error: field 'm_ppp_netif' has incomplete type 'netif' struct netif m_ppp_netif; ^
Any idea what i'm missing?
-Mike
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Fran, the master branch is correct. You normally can use the defaults for all sdkconfig variables we haven't added to the template yet. I've attached my current sdkconfig. It only excludes bluetooth because that currently needs too much memory. Regards, Michael Am 03.06.2018 um 19:42 schrieb Fran Terry:
Hi Mark,
Also having the same issues here, if you follow the instructions,the 2.1 branch doesn't contain components/heap, have switched to master branch, however support/sdkconfig.default.hw31 seems to be missing a lot of configuration, get asked lots of questions, such as:
'make' warns on undefined variables (MAKE_WARN_UNDEFINED_VARIABLES) [Y/n/?] (NEW)
*
* Bootloader config
*
Bootloader log verbosity
1. No output (LOG_BOOTLOADER_LEVEL_NONE)
2. Error (LOG_BOOTLOADER_LEVEL_ERROR)
3. Warning (LOG_BOOTLOADER_LEVEL_WARN)
4. Info (LOG_BOOTLOADER_LEVEL_INFO)
5. Debug (LOG_BOOTLOADER_LEVEL_DEBUG)
6. Verbose (LOG_BOOTLOADER_LEVEL_VERBOSE)
choice[1-6?]: 3
SPI Flash WP Pin when customising pins via efuse (read help) (BOOTLOADER_SPI_WP_PIN) [7] (NEW)
VDDSDIO LDO voltage
1. 1.8V (BOOTLOADER_VDDSDIO_BOOST_1_8V) (NEW)
2. 1.9V (BOOTLOADER_VDDSDIO_BOOST_1_9V) (NEW)
choice[1-2?]:
I've tried to answer as many as I believe are to be correct, however I guess the question is, is the master branch correct for esp-idf and does anyone have a sdkconfig that has all the correct answers for this version?
Thanks
Fran
On 23 April 2018 at 01:33, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Michael,
Do you still have the old sdkconfig around? If so, please do a ‘diff -u support/sdkconfig.default.hw31 sdkconfig’ so we can see what is different.
Regards, Mark
> On 22 Apr 2018, at 4:44 PM, Michael Stegen <michael@stegen.com <mailto:michael@stegen.com>> wrote: > > Mark, > > Copying support/sdkconfig.default.hw31 to sdkconfig fixed the issue, thanks! > > -Mike > > > > Op 21-4-2018 om 16:46 schreef Mark Webb-Johnson: >> Can you try copy support/sdkconfig.default.hw31 to sdkconfig to give a standard set of defaults (those used for production). You will then need to adjust the UART path appropriately. >> >> Also, please ‘git pull’ on each of the projects, to make sure you have the latest sources. >> >> Regards, Mark. >> >>> On 21 Apr 2018, at 10:30 PM, Michael Stegen <michael@stegen.com <mailto:michael@stegen.com>> wrote: >>> >>> Steve, >>> >>> Thanks for your suggestion. >>> I tried it ( git submodule update --init) and it did install mongoose in the correct folder. >>> >>> However, as you already noticed, this was not the solution to the problem. >>> >>> Exact same error also happens on a Ubuntu 16.04 installation i did. >>> I'm clearly missing something... but what? >>> >>> -Mike >>> >>> >>> Op 21-4-2018 om 8:43 schreef Stephen Casner: >>>> Mike, >>>> >>>> Separately cloning mongoose is not the usual procedure. Normally it >>>> is just "git submodule update" after cloning OVMS. That is not an >>>> explanation for the compilation error you encountered, though. >>>> Something else is missing. >>>> >>>> -- Steve >>>> >>>> On Fri, 20 Apr 2018, Michael Stegen wrote: >>>> >>>>> Hi OVMS v3 devs, >>>>> >>>>> In preparation of receiveing the module, i'm trying to compile what's >>>>> currently on github. >>>>> But while doing so, i'm running into problems >>>>> >>>>> I did the following: >>>>> Install the toolchain (windows) >>>>> >>>>> cd ~/esp >>>>> git clone --recursive https://github.com/openvehicles/esp-idf.git <https://github.com/openvehicles/esp-idf.git> >>>>> cd .. >>>>> git clone https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3.git <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3.git> >>>>> then in the /components/mongoose/ folder did: >>>>> git clone https://github.com/openvehicles/mongoose.git <https://github.com/openvehicles/mongoose.git> >>>>> >>>>> It now does compile up to the following error message: >>>>> >>>>> In file included from >>>>> C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.h:34:0, >>>>> from >>>>> C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_peripherals.h:67, >>>>> from >>>>> C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32can/src/esp32can.cpp:42: >>>>> C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:63:5: >>>>> error: 'ppp_pcb' does not name a type >>>>> ppp_pcb* m_ppp; >>>>> ^ >>>>> C:/msys32/home/Mike/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/gsmpppos.h:64:18: >>>>> error: field 'm_ppp_netif' has incomplete type 'netif' >>>>> struct netif m_ppp_netif; >>>>> ^ >>>>> >>>>> Any idea what i'm missing? >>>>> >>>>> -Mike >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> > > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
The unit looks really nice, though it seems that the top shell is a tad too wide and overlaps the bottom piece by nearly a mm on one corner.
The enclosures are injection moulded, so should be pretty accurate on tolerances. Is it affecting the ability to close the case for you? Or just a slight bulge?
adhesive on the flap of the padded envelope.
Yeah, the padded envelope is not amazing. It offers protection, but the glue can get everywhere. At least it is easy to remove. For future production runs, we’re thinking of switching to a cut-out foam box like this. It costs a little bit more, but seems a much better solution.
My intent is to play "customer" with this unit, only using officially released code, updated through typical methods (i.e. not via the developer's kit) unless I need to do otherwise.
That would be very helpful. Regards, Mark.
On 14 Apr 2018, at 6:49 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Mark,
The 3.1 module arrived in today's mail. I haven't plugged it in yet, but two "unboxing" observations...
The unit looks really nice, though it seems that the top shell is a tad too wide and overlaps the bottom piece by nearly a mm on one corner. And, not evenly, at that; it's like the corner by the Vehicle connector got stretched a bit outward (or the other half pushed inward). The other two sides are all pretty evenly matched. The 3.0 proto unit was not like this. {shrug}
Also, the two SMA dust caps seemed to have had some reaction with the adhesive on the flap of the padded envelope. They were stuck to the flap, pulled away from the connectors (so, not much dust protection), and the adhesive on the flap seemed to be very gooey in that area. The caps seemed to have been more or less unaffected, so it's more of a cosmetic issue. Perhaps they could point the module in the other direction (SMA end first), to prevent this in the future?
My intent is to play "customer" with this unit, only using officially released code, updated through typical methods (i.e. not via the developer's kit) unless I need to do otherwise. I've got some short-term distractions through the weekend, but will take it out for a spin next week.
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (6)
-
Fran Terry -
Greg D. -
Mark Webb-Johnson -
Michael Balzer -
Michael Stegen -
Stephen Casner