search

ammolytics / projects

Source code and instructions for do-it-yourself projects.
https://blog.ammolytics.com
MIT License
47 stars 20 forks source link

IOS problems or generic? #31

Closed itchyTF closed 4 years ago

itchyTF commented 4 years ago

Not sure if I was supposed to start a new issue or tag along with #28.

With help from Eric I was able to get my IOS app to work ONCE. That was after I configured the scale (except for the units). It became obvious that I needed to configure the units after I tried using the app and looking at the logs. After setting the units I wasn't able to get a connection again. Eric said the serial connection needs to be good before Bluetooth can connect. Based on the logs he said it looks like the USB-to-serial adapter driver is the problem. Is the driver within Raspbian or the image? Isn't there a more robust driver out there? Shouldn't the Bluetooth connection be independent of the serial? Bluetooth is between the Pi and the app not the scale.

Another issue is the unit designator in the app only shows g even when toggled between grams and grains.

itchyTF commented 4 years ago

Tried again today. First try no Bluetooth connect. Checked the scale configuration - OK didn't change anything. Power cycled the Pi, got the same error at the bottom of the boot sequence - ttyusb0: p12303_get_line_request - failed: -32 but this time I got a Bluetooth connection! What gives? Still nothing out of pin 12 after hitting Go button. Put a 100 grain target in the app with 7 grains on the scale. No pin 12 output. I'm assuming physical pin 12 (GPIO 18).

erichiggins commented 4 years ago

Let's separate a few things so they are easier to understand and therefore, debug.

Things I've found helpful:

itchyTF commented 4 years ago

Thanks for the reply. It seems to me that separating dependencies, where possible, would be preferable. Might make debugging easier.

What does the code look for when detecting the scale?

I haven’t modified the ecosystem file and I’m monitoring pin 12 with a scope. Initially at 20ms/div then 50. No activity. Don’t know the on/off periods but I figured I’d see something in a total of 200 or 500 ms.

Using your pre-built image.

Cables are always connected. Scale is always plugged in. Powered the Pi with the scale in both standby mode and ON. Connection problems with both. Most of the attempts have been in ON mode.

I have left the scale plugged in overnight. Surprises me that that would cause issues.

Would the motor on/off info show up in the logs?

On Sun, Jan 12, 2020 at 5:44 PM Eric Higgins notifications@github.com wrote:

Let's separate a few things so they are easier to understand and therefore, debug.

  • The OpenTrickler software that runs on the Pi will only "advertise" itself on Bluetooth after it detects the scale. (checks every 250ms) Reference in code https://github.com/ammolytics/projects/blob/develop/trickler/peripheral/lib/index.js#L61-L69
  • If a scale is never detected, it will never advertise itself on Bluetooth. I'm open to suggestions on whether or not this should be the case. If the scale isn't working, it's still a blocker, but it might be able to let the app know.
  • The ttyUSB0: pl2303_get_line_request - failed: -32 message doesn't always indicate failure.
  • There aren't alternative drivers for the USB/serial cable in Linux, but there are slightly different versions. I can check that to see if any recent changes might help with the flakiness.
  • Without modification of ecosystem.config.js, the trickler motor does use physical pin 12. Reference pin map https://pinout.xyz/
  • How are you checking pin 12 for output? Because it gets switched on and off pretty rapidly, a multimeter/voltmeter may not be able to read it.
    • Try checking the logs while running to see if it gives any clues
    • Try an LED to see if it flashes
  • If you're using the pre-built images, it's no longer using Raspbian.

Things I've found helpful:

  • Connect the serial-to-USB cables between the Pi and scale before turning them on.
  • Power on the scale before powering on the Pi.
  • Don't leave the scale powered on or even plugged in overnight. For some reason, this seems to cause issues with the scale.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ammolytics/projects/issues/31?email_source=notifications&email_token=AOIBWJYGFLCNIGUOZBDZ4Y3Q5OMM7A5CNFSM4KFTUJJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXGJAA#issuecomment-573465728, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIBWJ4U32E242BQDUAQGQDQ5OMM7ANCNFSM4KFTUJJA .

erichiggins commented 4 years ago

What does the code look for when detecting the scale?

The OpenTrickler Pi code thinks the scale is "ready" when:

Don’t know the on/off periods but I figured I’d see something in a total of 200 or 500 ms.

The speeds are defined here in ms (milliseconds). The speed used is determined by how much weight still needs to be trickled (measured in "ticks", which is just weight diff / scale precision).

I have left the scale plugged in overnight. Surprises me that that would cause issues.

I was surprised too, but I've definitely experienced it on multiple occasions.

Would the motor on/off info show up in the logs?

Yes, as well as it can. Here's the code that logs when the motor is activated. As far as I know, Pi has no way to tell if anything is pulling current or if anything is attached to a pin.

Shooter0423 commented 4 years ago

@erichiggins just wondering, does the program keep checking while open trickler is running that the scale and bt are ready or is that code that you noted as "Reference …" only running when starting up.

erichiggins commented 4 years ago

@Shooter0423 As mentioned, it keeps checking every 250ms until the scale is "ready'. The code linked is also what you'd see in the logs where it keeps checking over and over.

itchyTF commented 4 years ago

I believe there is a difference between precision and resolution. Couldn’t find precision in the specs. In case you meant resolution it’s about .02 grains. So I had a target weight of 100 grains with 7 grains on the scale. According to your code it looks like the speed would be very fast with a period of 140 ms. I should have seen 1 period at 20ms/div and 3-1/2 periods at 50ms/div.

On Sun, Jan 12, 2020 at 7:35 PM Eric Higgins notifications@github.com wrote:

What does the code look for when detecting the scale?

The OpenTrickler Pi code thinks the scale is "ready" when https://github.com/ammolytics/projects/blob/develop/trickler/peripheral/lib/and-fxfz.js#L155-L164 :

  • weight reads a number
  • unit reads a valid option
  • The scale reports as "stable"
  • The scale has been "stable" for at least one second.

Don’t know the on/off periods but I figured I’d see something in a total of 200 or 500 ms.

The speeds are defined here https://github.com/ammolytics/projects/blob/develop/trickler/peripheral/lib/motor.js#L10-L19 in ms (milliseconds). The speed used is determined https://github.com/ammolytics/projects/blob/develop/trickler/peripheral/lib/trickler.js#L149-L176 by how much weight still needs to be trickled (measured in "ticks", which is just weight diff / scale precision).

I have left the scale plugged in overnight. Surprises me that that would cause issues.

I was surprised too, but I've definitely experienced it on multiple occasions.

Would the motor on/off info show up in the logs?

Yes, as well as it can. Here's the code that logs https://github.com/ammolytics/projects/blob/develop/trickler/peripheral/lib/trickler.js#L103 when the motor is activated. As far as I know, Pi has no way to tell if anything is pulling current or if anything is attached to a pin.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ammolytics/projects/issues/31?email_source=notifications&email_token=AOIBWJ6JP37IYB2NC2PJTBTQ5OZN3A5CNFSM4KFTUJJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXI4VA#issuecomment-573476436, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIBWJ67XYVE3VION5537SDQ5OZN3ANCNFSM4KFTUJJA .

itchyTF commented 4 years ago

App was working for a while. Did disconnect by itself.

I guess my learning curve is steeper that it should be. When entering a target weight I saw that keyboard button appear but didn't realize that is what sends the weight to the Pi. I thought tapping on the units also sent the data. Another Duh! Doing that I finally saw pulses!!

Eric, I believe you said the ticks are the weight difference / precision. What number are you using for precision?

How would I be able to play around with the speeds and use them? I'd like to try a fixed period and just change the ON time.

erichiggins commented 4 years ago

FYI: I'm traveling for work this week and will be slow to respond.

Doing that I finally saw pulses!!

Excellent!

What number are you using for precision?

You were right w/ your correction -- I meant resolution. It's 0.02 gr and 0.001 g.

How would I be able to play around with the speeds and use them?

Pull the microSD out of the Pi, plug it into your computer and change the stuff in the code partition to work however you like.

itchyTF commented 4 years ago

Put the sd card in computer and it comes up as Boot(E:). No sub drives but an overlay folder, no code folder.

On Mon, Jan 13, 2020 at 5:55 PM Eric Higgins notifications@github.com wrote:

FYI: I'm traveling for work this week and will be slow to respond.

Doing that I finally saw pulses!!

Excellent!

What number are you using for precision?

You were right w/ your correction -- I meant resolution. It's 0.02 gr and 0.001 g.

How would I be able to play around with the speeds and use them?

Pull the microSD out of the Pi, plug it into your computer and change the stuff in the code partition to work however you like.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ammolytics/projects/issues/31?email_source=notifications&email_token=AOIBWJZSE4VMUXYWGM423TDQ5TWNVA5CNFSM4KFTUJJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI2TKDQ#issuecomment-573912334, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIBWJ72EOTZK7LOQGTAXYTQ5TWNVANCNFSM4KFTUJJA .

itchyTF commented 4 years ago

Got a chance to play with it today. It took a few power cycles before I got a BT connect. Tried putting the SD card in the windows computer to edit the motor speeds but all I saw was boot(E:) and an overlay folder. No code "drive" or folder.

Decided to try the Mac and code showed up. Now I can play.

Looks like the weight delta x 100 = ticks. At least while in grains.

Shooter0423 commented 4 years ago

Hey @itchyTF Not sure what you're wanting to change. But if you are wanting to change how the trickler behaves, look in the file, trickler.js. You will see how the vibro motor steps through multiple "speed". I built my own trickler body and stand and im using Tac for powder. Tac is pretty fine as compared to stick powders like varget. I think it will work, but I would rename the original trickler.js so if you have to go back to the original it already there.

Windows is kind finicky when dealing with the sd created for rpi,

itchyTF commented 4 years ago

Shooter - (below comment to Eric)

Eric - While reading up on PWM again in the Broadcom spec I came across this and was wondering if it might have anything to do with the flakiness of the scale or Bluetooth connection. (Didn't know how to do superscripts here).

1.3 Peripheral access precautions for correct memory ordering The BCM2835 system uses an AMBA AXI-compatible interface structure. In order to keep the system complexity low and data throughput high, the BCM2835 AXI system does not always return read data in-order 2. The GPU has special logic to cope with data arriving out- of-order; however the ARM core does not contain such logic. Therefore some precautions must be taken when using the ARM to access peripherals.

Accesses to the same peripheral will always arrive and return in-order. It is only when switching from one peripheral to another that data can arrive out-of-order. The simplest way to make sure that data is processed in-order is to place a memory barrier instruction at critical positions in the code. You should place:

• A memory write barrier before the first write to a peripheral. • A memory read barrier after the last read of a peripheral.

It is not required to put a memory barrier instruction after each read or write access. Only at those places in the code where it is possible that a peripheral read or write may be followed by a read or write of a different peripheral. This is normally at the entry and exit points of the peripheral service code.

As interrupts can appear anywhere in the code so you should safeguard those. If an interrupt routine reads from a peripheral the routine should start with a memory read barrier. If an interrupt routine writes to a peripheral the routine should end with a memory write barrier.

2 Normally a processor assumes that if it executes two read operations the data will arrive in order. So a read from location X followed by a read from location Y should return the data of location X first, followed by the data of location Y. Data arriving out of order can have disastrous consequences. For example:

a_status = pointer_to_peripheral_a; b_status = pointer_to_peripheral_b;

Without precautions the values ending up in the variables a_status and b_status can be swapped around.

It is theoretical possible for writes to go ‘wrong’ but that is far more difficult to achieve. The AXI system makes sure the data always arrives in-order at its intended destination. So:

pointer_to_peripheral_a = value_a; pointer_to_peripheral_b = value_b;

will always give the expected result. The only time write data can arrive out-of-order is if two different peripherals are connected to the same external equipment.

Shooter - My initial problem was I couldn't see the code in Windows because I didn't see the code: drive. I can on the Mac. I was messing with the PWM speeds and just commented out the original lines and replaced them with mine. Figured not enough changes to warrant a different file. Eric has implemented a quasi PWM. He is manually setting frequency ((period) ON + Off time) and ON time (pulse width). With normal PWM implementation the frequency is set to one value and just the pulse width is varied. Also PWM is usually at a higher frequency. I'm guessing if Eric's method is limited to miliseconds, frequency will also be quite limited. There is capability within the processor to do true PWM with higher frequencies. I was playing with it when I just had Raspbian loaded on the SD card.

erichiggins commented 4 years ago

@itchyTF You didn't provide references, but I think I found what you were citing.

What this is talking about is the serial/UART interface that's available on the Pis through the GPIO pins. That's not the same as accessories connected through the Pi's USB port, like we're doing.

This is probably confusing because this article mentions the words "serial", "adapter", "peripheral", and "USB", all of which sound like the same use-case, but it isn't. What it's talking about is accessing the Pi with a USB-to-TTL Serial cable such as this one from AdaFruit.

itchyTF commented 4 years ago

@erichiggins Sorry, should have provided a reference. It was section 1.3 in https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

itchyTF commented 4 years ago

@erichiggins I was thinking the above reference might apply to doing "reads" from the USB port and the BT area.

erichiggins commented 4 years ago

@itchyTF what it's referencing applies more accessories that plug onto the gpio pins, like "shield" boards, or other on-board peripherals. If the Pi couldn't use USB and Bluetooth at the same time, they'd have real issues.

I have some ideas that may help with the stability issues that I'll try when I get back from this trip. If you're looking for a technical project to dig into in the meantime, you may want to familiarize yourself with the code in this repo (same as on the micro SD' scode partition).

itchyTF commented 4 years ago

repo must be short for something. ?

On Thu, Jan 16, 2020 at 1:33 PM Eric Higgins notifications@github.com wrote:

@itchyTF https://github.com/itchyTF what it's referencing applies more accessories that plug onto the gpio pins, like "shield" boards, or other on-board peripherals. If the Pi couldn't use USB and Bluetooth at the same time, they'd have real issues.

I have some ideas that may help with the stability issues that I'll try when I get back from this trip. If you're looking for a technical project to dig into in the meantime, you may want to familiarize yourself with the code in this repo (same as on the micro SD' scode partition).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ammolytics/projects/issues/31?email_source=notifications&email_token=AOIBWJZKJJ2A5K7TO4KSWR3Q6CSA7A5CNFSM4KFTUJJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJFCO2A#issuecomment-575285096, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOIBWJ5XITQTNSIHGVDPGQ3Q6CSA7ANCNFSM4KFTUJJA .

erichiggins commented 4 years ago

Yes. Repo is short for repository, as in source code repository. That's what GitHub is.

This is what you're looking for: https://github.com/ammolytics/projects/tree/develop/trickler/peripheral/lib

itchyTF commented 4 years ago

Some observations / comments while experimenting with the pulse widths.

I had a target weight of 5 gr and the trickler stopped at 4.60 for quite a while.

Might be handy to set up different cases (pulse widths/periods) and/or motor speeds for different powder types (long stick, short stick, flake, ball, etc.).

Pulse widths and periods are unstable. My intended 4ms On/ 21 ms Off resulted in 5.3-8.1ms On and 24.7-27ms Off.

I believe the “true” PWM” peripheral would be much more stable.

I have a few short videos depicting this, just don’t know how to get them from the phone to here.

itchyTF commented 4 years ago

@erichiggins Here is one of the videos. No point of adding any more, the others were at different duty cycles but acted the same. The trigger point is at the first division, everything else is referenced to that.

Pulse jitter

itchyTF commented 4 years ago

@erichiggins You mention in your video what cup you use with the scale to catch the powder but I couldn't make out what you said. Who makes it?

itchyTF commented 4 years ago

@erichiggins , @Shooter0423 A FWIW - Regarding a Dandy trickler While playing around with pulse widths and periods I noticed while on the single kernal setting the height of the reservoir makes a big difference. With the reservoir almost at the top of the rod the trickle was single kernal but when it was lowered close to the bottom it sped up considerably. If I think about it, it makes sense. Just thought I'd pass it on.

erichiggins commented 4 years ago

@itchyTF Let's keep the conversation in this thread on the original topic. It sounds like you did have some success connecting to the new PI image using the iOS app from TestFlight -- that's great!

I know there is still work to be done to enhance the reliability of that connection, but that's more on the Pi side than on the iOS side.

I'm closing this particular ticket out for now. Here are links to a few others where you can add any comments you have on those specific topics: