ProffieOS 7.7 Beta (done)

Baldusi, can you please start a new thread, there is soo much going on here that I’m not sure if you’re testing stuff, need help, or if there is something you want me to figure out.

I’d like to figure out the whole port disconnect thing.
Then there is whatever you’re doing with blade ID.
Do you have a 33k pullup resistor?

I will make new thread. But the disconnect issue was solved by your change.
I have three hilts, each with its own issues. But I wanted to stress test the Blade ID changes.

  • In this hilt I have a 33k pullup resistor, Blade Present pin, plus a Stok V3 Illuminated PCB withe the PCB pixels on Data 2. So, it’s the ideal platform for testing Blade ID.
  • As I stated, I’ve got some weird readings on a charging bladeplug (the one I used to charge through PCB). I will assemble a new one to check of it has some issue.
  • I’ve also got quite a few readings where the Blade Present shows that a blade is present but reads No Blade value. This happened a lot more with bladeplugs than blades, which might indicate a that I was not pushing it back enough and/or the Blade Present pin engages first and the Blade Id test goes so fast that that I don’t push the plug back enough.
  • I haven’t been able to quantify if multi polling Blade ID helps reduce the variance of reading.
  • Polling each second without Blade Present seems to be working fin.
  • I would like to test Blade ID with constant polling and Blade Present to see if something breaks down.
  • And also test Blade ID in the hilt with ECO PCB, because even though that hilt have a 22k pullup resistor, I got some weird reading. Even changing when the PCB was illuminated.
  • I will start a new thread tomorrow just to test the Blade ID stuff.

Now to the issues of this hilt:

  1. This hilt (a Revan Light) appears to have trouble with reading hum at times. But the SD Card is barely doing 12 tracks.
  2. It appears to not be reading movements, but I got a few swingl, and the OLED display is working. Used to work fine in motion when I installed it. I might also tey to delete the config.ini/tmo and switch to saber.h because the physical switches are not smooth and I might be putting it on mute mode.
  3. *The serial monitor diaconnect was solved by your change in the #if 0. This issue was shared by my three hilts at hand.
  4. The other hilt with 33k pullup resistor and Illuminated PCB with Blade Present and pixels on Data 2 is my Bane hilt. This hilt is the one that can’s read any SD card. Even the ones being used by the other hilts.
  5. The third hilt, has a 22k resistor but the ECO illuminated PCB which mirrors the PCB pixels on Data 1 and I get weird readings and had trouble with disconnects.
  6. I will dedicate a new thread to testing just Blade ID issues there, while we try to troubleshoot the other issues (motion sensor and SD card issues)here or wherever you tell me to do it.

It’s not a solution though, it disables all low-power modes.
It was just a first step to narrow down what is actually causing the problem.

I tried that secret line with OS-7.4, and it did indeed seem to fix it. I’m still in the process of getting gyro and clash figures from serial monitor, but it’s such a huge stream of data and I have no idea what I’m looking at so I can’t really interpret anything. But will try to post the comparisons here soon. :slight_smile:

A new thread would be nice I think, this thread is already very long. :slight_smile:

1 Like

I think I spoke too soon - I’m not sure that secret define did work after all, as leaving it connected to serial monitor to test it seems to be affecting things. :confused:
The case continues.
Will start a new thread if and when more evidence arises. :slight_smile:

Ok, I’ve solved most of my other problems, so I wanna solve this one. I get no messages from the gyro, but I do have a working OLED. If the display works, I should discard the off chance that it is making a short or something or should I desolder the OLED before looking for a failed gyro?

I have os7 on 2 crossguards I built. I had issues with led1 on both. Coincidence? Or have any other testers had issues with Fet1 leaking or acting wonky?

Incidentally, my OLED works but when I put monitor gyro I get nothing on the serial terminal. I have not even been able to find that command on the source code.

What kind of issues?
Does using ProffieOS 6.x make the problem better/worse?
Maybe start a new thread, post your config and I’ll see if I can replicate it.

monitor gyro lives in common/monitor_helper.h
If you get nothing from it, that probably means that your motion chip is not working.
Normally, that should produce a lot of motion chip timout errors in the serial monitor though…

But I have zero timeouts. Should I just disconnect the OLED and see what happens?

I’m a little confused by that…

Hmm, wait…
Did you try turning the saber on after running “monitor gyro” ?

I did monitor gyro a few times because I didn’t had any echo on wheather it was on or off. I put monitor, turned on, moved it a lot, then typed monitor again, moved, then type again, then turned off. Nothing showed up:

I2C init..
Display initialized.
Amplifier off.
Unmounting SD Card.
Time = 3000. PLI_OFF_TIME expired.
DISPLAY SLEEP
I2C sleeping..
Booster off.
Battery voltage: 3.73
Welcome to ProffieOS v7.5
For available serial commands, see:
https://pod.hubbe.net/tools/serial-monitor-commands.html
Battery voltage: 3.73
EVENT: Power-Pressed#1 millis=42043
EVENT: Power-Pressed millis=42043
EVENT: Power-Released#1 millis=42181
EVENT: Power-Released millis=42181
EVENT: Power-Shortclick#1 millis=42181
EVENT: Power-Shortclick millis=42181
Ignition.
unit = 0 vol = 0.00, Playing JuanSith/RReborn/hum/hum01.wav
channels: 1 rate: 44100 bits: 16
unit = 1 vol = 0.50, Playing JuanSith/RReborn/out/out4.wav
channels: 1 rate: 44100 bits: 16
humstart: 1800
unit = 2 vol = 0.00, Playing JuanSith/RReborn/swingl/swingl2.wav
channels: 1 rate: 44100 bits: 16
unit = 3 vol = 0.00, Playing JuanSith/RReborn/swingh/swingh2.wav
channels: 1 rate: 44100 bits: 16
DISPLAY WAKEUP
I2C init..
Display initialized.
Playing JuanSith/RReborn/swingl/swingl2.wav
channels: 1 rate: 44100 bits: 16
Playing JuanSith/RReborn/swingh/swingh2.wav
channels: 1 rate: 44100 bits: 16
Playing JuanSith/RReborn/swingl/swingl2.wav
channels: 1 rate: 44100 bits: 16
Playing JuanSith/RReborn/swingh/swingh2.wav
channels: 1 rate: 44100 bits: 16
Battery voltage: 3.65
Playing JuanSith/RReborn/swingl/swingl2.wav
channels: 1 rate: 44100 bits: 16
Playing JuanSith/RReborn/swingh/swingh2.wav
channels: 1 rate: 44100 bits: 16
Playing JuanSith/RReborn/swingl/swingl2.wav
channels: 1 rate: 44100 bits: 16
Playing JuanSith/RReborn/swingh/swingh2.wav
channels: 1 rate: 44100 bits: 16
Battery voltage: 3.63
Playing JuanSith/RReborn/swingl/swingl2.wav
channels: 1 rate: 44100 bits: 16
Playing JuanSith/RReborn/swingh/swingh2.wav
channels: 1 rate: 44100 bits: 16
EVENT: Power-Pressed#1 ON millis=82432
EVENT: Power-Pressed ON millis=82433
EVENT: Power-Released#1 ON millis=82645
EVENT: Power-Released ON millis=82645
EVENT: Power-Shortclick#1 ON millis=82645
unit = 1 vol = 0.50, Playing JuanSith/RReborn/in/in2.wav
channels: 1 rate: 44100 bits: 16
No sounds found: pstoff
Playing JuanSith/RReborn/hum/hum01.wav
channels: 1 rate: 44100 bits: 16
Time = 3000. PLI_OFF_TIME expired.
DISPLAY SLEEP
I2C sleeping..

Normally there is a message like “motion chip … 105 found” when proffieos starts. Do you see that anywhere?

Yes. I have had Second 7 beta but what about Seven-ises???

1 Like

This is what I get:

unit = 0 vol = 0.50, Playing JuanSith/RReborn/boot/boot4.wav
channels: 1 rate: 44100 bits: 16
Playing JuanSith/RReborn/boot01.pbm
I2C init..
Display initialized.
Amplifier off.
Unmounting SD Card.
Time = 3000. PLI_OFF_TIME expired.
DISPLAY SLEEP
I2CWelcome to ProffieOS v7.5
For available serial commands, see:
https://pod.hubbe.net/tools/serial-monitor-commands.html
Battery voltage: 3.73
Battery voltage: 3.73

I had to close down and open again the serial monitor for it to show I2CWelcome to ProffieOS v7.5 after I did a reset. If you say it, I will desolder the OLED wires.

The motion chip … message only happens on startup though, not on connection…
Anyways, I recommend comparing to a working setup to see what should happen, then start messing with the soldering.

I think I may have found my vocation in life - it’s taking perfectly good software and managing to break it without doing anything especially complicated with it! :confused:

I’m finishing up a busy little install and the front accent strips are flickering white using OS 7.5. But if I go back to OS 7.0 they work fine. Tried uploading both versions twice, both times with the same result. I also had some of the LEDs freeze full white under 7.5, but I don’t know what caused it and I couldn’t recreate it once I got the camera out.

Config is below. It’s busy but nothing too complicated. The strips in question are described in the config as Accent Strips, Short, Front and are fed from shared LED pads with the main blade but have their own data line (Data 3). Blade array has them as a reverse sub blade so I could get the direction right (as they are wired from the front).

The only other funny I’ve done is to have Blade Detect set up to Pin 8 (RX) so that when the chassis is inserted inside the hilt, everything runs the same as outside the hilt except the spinning motor is set to not spin (so it doesn’t make a noise or cause false clashes, as you can’t see it anyway once it’s in the hilt). I haven’t been able to test that yet as I need to glue the board down, and I don’t want to do that until any other wrinkles are ironed out.

Let me know if it’s something I’ve done wrong in the config, but if not, here’s hoping it’s an easy fix. :crossed_fingers:

Here’s a video of the symptoms:

And here’s the config:

1 Like

Well if it’s going to be your vocation, maybe I should help you become better at it. :slight_smile:

I can’t run the config file you sent me as-is because it uses a prop file that I don’t have, and when I try to run it with the basic prop, it runs out of memory.

Now, I can start cutting it down to fit and so forth, but when I do that, there is always a chance that I end up cutting whatever is causing the actual problem, so it would be better if you did that before sending it to me.

In fact, in the best possible scenario, you cut config files to the barest, smallest possible. Maybe you’ll find out what the problem is when you do that, and if you don’t, there is a lot less for me to explore when I get it, which is always nice.

Nobody has do do this of course, but hey, might as well be good at it if it’s your vocation and all, right? :slight_smile: