Replies: 30 comments 59 replies
-
|
First: you shouldn't change rowerProfile.js, as that file gets overwritten with every update. Instead, you should include a rowerSettings section in config.js. So in your config.js you should replace/add: I would change the maximumImpulseTimeBeforePause to at least 6 seconds: in the current main version, when ORM misses a stroke it automatically would lead to a pause. |
Beta Was this translation helpful? Give feedback.
-
|
in original rowerProfile.js I add my settings called "openergo" is it ok? |
Beta Was this translation helpful? Give feedback.
-
|
You shouldn't change rowerProfile.js, as that file gets overwritten with every update. If you want to add something there, you need to provide the settings and some raw recordings (minumum of 10 strokes) to us, so we can maintain it and it will be taken along with updates of OpenRowingMonitor. But updates take some time, as we do quite some tests before updates reach the field. But by far the simplest is to add the settings to the config.js, as my example shows. This way it won't get overwritten. |
Beta Was this translation helpful? Give feedback.
-
|
ok , I was confused. |
Beta Was this translation helpful? Give feedback.
-
|
my config js, I restarted the services but in this way monitor doesn't show progression. // rowerSettings: rowerProfiles.DEFAULT, |
Beta Was this translation helpful? Give feedback.
-
|
sorry, where is log file? |
Beta Was this translation helpful? Give feedback.
-
|
typically, you can see the logs in /var/log/syslog. So doing a
Can tell you if something has crashed when starting the service. |
Beta Was this translation helpful? Give feedback.
-
|
Jan 17 10:48:35 rowingmonitor npm[5220]: > [email protected] start |
Beta Was this translation helpful? Give feedback.
-
|
I use |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps you need to do a "killall node" as well. The gpio thread splits off after a restart, but it could be that it isn't killed in a crash. |
Beta Was this translation helpful? Give feedback.
-
|
no even with kill all doesn't work, but if I reset config.js as original work again. |
Beta Was this translation helpful? Give feedback.
-
|
find!! |
Beta Was this translation helpful? Give feedback.
-
|
Great! It always is something stupid like that. Problem is, you can look a 1000 times and still miss it.... |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I tryed some rowing but In my opinion meters go to much faster.
|
Beta Was this translation helpful? Give feedback.
-
|
Hi, I would set both loglevels to 'debug', restart ORM and check ORM's output. Then do some pulls and check whether drive and recovery are recognized correctly. |
Beta Was this translation helpful? Give feedback.
-
|
These are the most important settings you should start playing with and since you enable auto adjust drag factor, the What I would do is record 10-20 strokes of raw data that can be played back making testing easy. In the server.js there is a commented function at the bottom: /*
replayRowingSession(handleRotationImpulse, {
// filename: 'recordings/2021/04/rx800_2021-04-21_1845_Rowing_30Minutes_Damper8.csv', // 30 minutes, damper 10
realtime: true,
loop: false
})
*/You basically find the raw csv of the recorded 20 strokes, set |
Beta Was this translation helpful? Give feedback.
-
And don't forget |
Beta Was this translation helpful? Give feedback.
-
|
Hi, rowerSettings: { server.js ` service openrowingmonitor restart; journalctl -f -u openrowingmonitor what should I do? 2023-01-22_14-07-46_raw.csv.gz |
Beta Was this translation helpful? Give feedback.
-
|
Jan 22 14:07:46 rowingmonitor npm[1666]: stroke: 1, |
Beta Was this translation helpful? Give feedback.
-
|
Please upload this CSV file too: dyw_4magnets.csv So I can run locally and test. How many strokes are we looking for? |
Beta Was this translation helpful? Give feedback.
-
|
Is empty.
No data.
Il giorno mar 24 gen 2023 alle 20:17 Abasz ***@***.***> ha
scritto:
… Please upload this CSV file too: dyw_4magnets.csv
So I can run locally and test. How many strokes are we looking for?
—
Reply to this email directly, view it on GitHub
<#115 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A5AGSVAC7BA22DRFQTECEBTWUATDHANCNFSM6AAAAAAT5SGDXM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Then it should not come as a surprise that it does not replay anything in the simulation :):):) First you needed to record and then replay for tests |
Beta Was this translation helpful? Give feedback.
-
|
I Tried many row , but file is always empty. |
Beta Was this translation helpful? Give feedback.
-
|
Your server js is incorrect for this purpose! For initial recording you need to comment the simulator part out: This should be used once you recorded the row data as this plays the recording back form the csv and not for recording your storkes you are doing in real life |
Beta Was this translation helpful? Give feedback.
-
|
Ok now is clear. I’ll try tomorrow thanks for now |
Beta Was this translation helpful? Give feedback.
-
|
nothing , file server.js |
Beta Was this translation helpful? Give feedback.
-
|
Raw data files are not saved under the file name you choose. You can see in the logs where and how they are saved: saving session as raw data file data/recordings/2023/01/2023-01-22_14-07-46_raw.csv.gz... Tha above is from the logs you copied. Can you pleas have a look at that folder (I mean this: data/recordings/2023/01)? |
Beta Was this translation helpful? Give feedback.
-
|
yes i check that folder, but files is empty. |
Beta Was this translation helpful? Give feedback.
-
|
I beg to differ - the csv files are not empty. 14.923765917 "0,01" is quite a low value - on my setup with six magnets I do not get below 0.03 for a normal stroke and it takes about 10-15 decreasing values to get there. In your file this low value shows up immediately. What is the electronic setup you are using (hall sensor, reed swich, optical switches)? Cheers, |
Beta Was this translation helpful? Give feedback.
-
The OpenErgo machines typically use a bicycle wheel, which could have a quite low drag and inertia (i.e. no air capturing flaps). Then these speeds are doable quite fast. When people add flaps, the inertia increases quite fast, and then speed goes down. |
Beta Was this translation helpful? Give feedback.
-
|
yes, this is my flywheel |
Beta Was this translation helpful? Give feedback.
-
|
I use reed switch and 4 "square school magnet". previus file csv I did 20 stroke, but file has only 2 stroke. |
Beta Was this translation helpful? Give feedback.
-
|
As the meters are moving, ORM sees impulses and is processing them. It probably is stroke detection which is problematic. What version/branch did you install? |
Beta Was this translation helpful? Give feedback.
-
|
v1 beta |
Beta Was this translation helpful? Give feedback.
-
|
What happens when you turn the flywheel very slowly? Does ORM respond? |
Beta Was this translation helpful? Give feedback.
-
|
yes respond |
Beta Was this translation helpful? Give feedback.
-
|
Can you also provide the output of the logs that are generated along with the raw csv |
Beta Was this translation helpful? Give feedback.
-
|
if usefull I attach even syslog |
Beta Was this translation helpful? Give feedback.
-
|
only one stroke is detected |
Beta Was this translation helpful? Give feedback.
-
|
Can you try reducing the also can you try reducing this setting: |
Beta Was this translation helpful? Give feedback.
-
|
ok I'll try with this setting in config/config.js |
Beta Was this translation helpful? Give feedback.
-
|
First of all: please follow https://github.com/laberning/openrowingmonitor/blob/v1beta/docs/rower_settings.md as we do describe optimizing/creating settings from scratch. Just messing about with settings at random does not help in getting your settings in order. In V1Beta I looked at 2023-01-22_14-10-09_raw.csv.gz, and I see a lot of noise. Please just load your file in Excel, and see what realistic values are. Looking at that file, and @Gordon-Shumway2 's remark, I think a value of 0,026 for Please get this working first, before expecting ORM to perform miracles and detect strokes. You need to see a decent line in the time measurement first, instead of the messy chaos you see now. And please check what you upload before uploading: several raw files contained a single value or were empty. People like @Abasz and @Gordon-Shumway2 are always willing to help, but they do this in their spare time and you need to put some effort in as well. Having to download and open three files before getting any meaningful data does not increase people's willingness to help. |
Beta Was this translation helpful? Give feedback.
-
I recommend these low settings because I wanted to see if any signal is being picked up or there are some other issue. The noize log is what I wanted to two actually seebtaht kicks in. I think the issue is bounce that may come from the lack of necessary magnetic force to trigger the reed for the period of time it needs to work properly. What I mean here is that if the magnetic force is not sufficient to pull the tiny wire inside and conctinuasly bounces back it is not able to produce a stable reading. Since the reed is a spring inside the magent needs to counter the increasing sprig force when triggering |
Beta Was this translation helpful? Give feedback.
-
|
I tried with 2023-01-25_10-51-48_raw.csv.gz after no raw file created. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so based in the logs ORM detects signals but the signal is noisy (as stated: #115 (comment)) If you do a bit of research on reed switches you will find that they bounce a lot (these are mechanical switches in essence). What you need to do is what is said in this comment: #115 (reply in thread) But I would start with increaseing the Also what are school magnets? I use small like 4mmx4mmx2mm cilionderic neodymiu magnets not big once (smaller magnets tend to produce less noise on the reeds assuming they are close enough and strong enough. neodymium has strong traction as the reed needs to be stable for a few micro sec.). What I am trying to find out is that may be your magnets are not strong enough to pull the reed for sufficient time with the fast spinning and they bounce. On the reed switches datasheet you can find the stabilising time the Reed needs as well as the necessary magnetic force to work properly. |
Beta Was this translation helpful? Give feedback.
-
|
Data in lines 163 - 167 from 2023-01-25_10-51-48_raw.csv: 0,000090759 These times add up to 0.000557. As you have four magnets this would represent one revolution of your 28" wheel. That's roughly 2000 revolutions each second. I think your wheel would be torn apart by centrifugal forces if it rotated that fast. ==> the data supplied by the sensor is corrupt. ORM is trying to make sense of the data, hence the various lines about "noise filter corrected currentDt..." in 001.txt but the data is just too noisy. My guess: your sensor is broken or it bounces heavily or there is something wrong with the GPIO. |
Beta Was this translation helpful? Give feedback.
-
|
thank you for support.
|
Beta Was this translation helpful? Give feedback.
-
Let's start here. In comparison, a neodymium magnet of the same size as a ferrite magnet (the school magnet you refer to) is far stronger, so it is recommended in cases where space is limited. But the magnets you posted could work assuming they are close enough to the reed switch.
These values are good. Please notice the bounce time and the action time. The latter means that one hole operating cycle for the switch takes approx 1ms (1) close, 2) get stable for the reading, 3)release 4) get stable for reading). The former means that when the magnet gets close and closes the reed, the signal will bounce for about 0.6ms (meaning reliable reading should be available only after this time since within this time range it will trigger high-low with very short gaps, this is the noise). In practice this means that the magnet should be producing the magnetic force set forth by the data sheet (10-15AT in your case) for at least 0.6ms (i.e. when the magnet passes it should remain close to the reed for at least this amount of time, but more like 1ms otherwise you will get a lot of noise) What needs to be done is that 1) To achieve 2) you need to either use stronger magnet, or reduce the distance between the reed and magnet. For instance on my machine magnet is about 1mm far from the reed (so pretty close).
this value means that the reed does not need much magnetic force to close but also more susceptible to noise. This does not mean that this reed is not capable or needs changing. It just means settings needs tweaking. |
Beta Was this translation helpful? Give feedback.
-
|
better Hall sensor? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Luca, I cannot comment on the reed switch but I have been using a KY-003 hall sensor module with a Raspberry 3, Pi zero and Pi zero 2 for some years with very little issues. They work with the 3.3v used by the Raspberry. Mine has an LED which lights up when it is triggered which makes debugging a lot easier. Kind regards, |
Beta Was this translation helpful? Give feedback.
-
|
Look, it does not make sense to go on and change stuff without knowing what the implications are as this is really blind shooting... Yes, Hall sensors work, they produce less noise but the electric characteristics are different. For instance this hall needs at least 4.5 volt. Rpi has 3.3 on the Vout (hall has 3 pins, one gnd, one signal and one Vin). So while you may solve the noise issue, you will need to convert the 3.3 to 4.5 (or above) or route power from the Rpi main power supply (that is 5.1v). You can experiment with this but remote debugging electric circuit by nature is not possible, so I will not be able to help you :). So I would not start to go down this road unless you really know what you are doing and you have the necessary tools and knowledge. In this thread there is already more info in my view than needed to solve your issues you are having. Besides I have tested ORM both with Hall and Reed and when set up correctly they deliver nearly the same quality. |
Beta Was this translation helpful? Give feedback.
-
|
I guess Abasz' and my update crossed each other. Regarding the 3.3v/5v issue: the hall sensor you mentioned does require at least 4.5v so it would probably not work out-of-the-box. The module I referred to does indeed work with 3.3v. I have used two brands (one from Wingoneer, one from AZDelivery, both bought via Amazon) that work with 3.3v but I cannot guarantee that this will be the case with any and all KY-003 modules. Having said that I concur with what Abasz wrote: try not to change too many things at once. |
Beta Was this translation helpful? Give feedback.
-
|
Michael,
While you are correct that these modules could (and some cases do) work on the Rpi in practice, according to their data sheet they still rated for 4.5v to 24v operation voltage :) Just FYI these modules use the same Allegro hall that luca posted (3144EUA-S). This measn that if you supply less voltage, they will not deliver the characteristics stated in the data sheet (e.g. the required magnetic force will be different, they will not open fully and will not switch the hole 0-3.3v range etc.) Honestly, I use these sensor too (but I supply it with approx 4v from a lipo battery) and it works but I know what I am doing and how to debug if it would not have worked (I have the tools at home too). The reason I do not recommend this to OP is that it adds potential issues to trouble shoot (e.g. it could still happen that the magnetic force will not be sufficient to trigger the under powered hall, which I would be able to troubleshoot at home but I can not do it remotely) while the reed, having set up settings correctly (which is necessary any way) would also work. ORM v1beta was designed by Jaap in a way that hardware is less relevant and most things can be compensated by the settings which needs learning any way. Hence my recommendation is to start with settings and when those are at 80-90% start on the hardware side. Its easier to get those right with a "ceteris paribus" approach. |
Beta Was this translation helpful? Give feedback.
-
I have the feeling that the OP is turning way too many nobs at the same time, and thus the results are all over the place. This is the reason I made the setup guide: there is a decent path from an unknown machine to a working setup, but you have to be willing to perfect the knob's one at a time. I also learned the hard way that taking baby steps in the configuration is crucial. If the signal changes, so do all subsequent settings. So know what the first hurdle is you have to overcome, take the time to fix it, and only then move on to the next hurdle. In this case, you have a huge amount of impulses from the switch in a chaotic manner, so all metrics (distance, stroke count, etc.) can not be accurate yet. First step should always be looking at the raw data if those makes sense. As @Gordon-Shumway2 extremely adequately shows, 120.000 RPM is extremely unlikely as a speed, so the raw data needs improvement before progressing to the next stage. Obviously you are fighting a huge amount of noise. Stroke detection with this kind of data is irrelevant, when you still measure these kind of speeds. So fixing this issue (given the above potentially by replacing magnets/electronics) should take priority. As @Abasz points out, when there is a lot of noise, software based debouncing might become impossible, but increasing the debounce filter with 50 us at a time might help here. Key point is: change one thing at a time, and now what to expect. So either start with replacing magnets or changing the debounce filter. But first fix that, then the rest will follow. @Abasz : As a side note, I am glad we decided to switch to pigpio now, we now can measure 120.000 RPM flywheels quite well :) |
Beta Was this translation helpful? Give feedback.
-
|
ok I'll try to put reed more close to magnet and I'll change gpioMinimumPulseLength value. |
Beta Was this translation helpful? Give feedback.
-
|
This is an old 0.8.2 error message. Please switch to the V1Beta branch (see this small HowTo: #118) as the handling of errors and gpio noise filtering has improved significantly (the later thanks to the persistance to @Abasz ), and most settings you are changing relate to V1Beta. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Now you can rerun the test and slowly increase the gpioMinimumPulseLength to see if that removes the noise. |
Beta Was this translation helpful? Give feedback.
-
|
I did some tests, but I can't figure out the direction to go. minimumTimeBetweenImpulses: 0.026 minimumTimeBetweenImpulses: 0.020 minimumTimeBetweenImpulses: 0.030 minimumTimeBetweenImpulses: 0.030 minimumTimeBetweenImpulses: 0.0050 minimumTimeBetweenImpulses: 0.0050 minimumTimeBetweenImpulses: 0.0050 minimumTimeBetweenImpulses: 0.0001 |
Beta Was this translation helpful? Give feedback.
-
|
I read the guide but I can't find an answer to my questions. the last one I think is the best settings I've found, but isn't perfect, I should increase minimumTimeBetweenImpulses o decrease? I thoght syslog would be usefull, some gz file were written. 2023-01-26_15-47-49_raw.csv.gz |
Beta Was this translation helpful? Give feedback.
-
CSV files are written when no more strokes are detected. If stroke detection is not possible in a reliable way ORM cannot detect that strokes have ended. You can always force thec reation of CSV file by clicking on the reset icon.
currentDt is the time span between two readings of your sensor. A currentDt of 0.00081 sec is highly unlikely to be realistic. With four magnets this would equate to 0.00081 * 4 = 0,00324 seconds for one revolution of your wheel. That's more than 300 revolutions per second -> highly unlikely. The issue at heart is the noise from your sensor. If you take 2023-01-26_16-03-16_raw.csv, load it in Excel or OpenOffice calc and turn it into a diagram you will get this: You can see the general shape of your strokes but there are a lot of data points that are WAY too low - that's your sensor's noise. A detailed look at the first 50 data point shows this:
Look at the first ten data points: The noise is what you need to get rid of. Either by using another sensor/magnet combination or by trying to eliminate them through changing gpioMinimumPulseLength: See this documentation section:
|
Beta Was this translation helpful? Give feedback.
-
|
great explanation, thank you |
Beta Was this translation helpful? Give feedback.
-
I added this to the settings manual. Thanks for that one.
Thanks for this visualisation. I always used lines which becomes messy, but a column or scatter plot are much clearer in recognising the issue. I added a similar example from Luca's files to the manual as well, to help future users recognise signal bounce from the raw file. |
Beta Was this translation helpful? Give feedback.
-
|
I made some change in reed switch. |
Beta Was this translation helpful? Give feedback.
-
|
Please take a look at https://github.com/JaapvanEkris/openrowingmonitor/blob/v1beta_updates/docs/rower_settings.md#fixing-switch-bounce |
Beta Was this translation helpful? Give feedback.
-
|
the time between impulses is irrelevant at this moment (it will only trigger logging deviating values to syslog). Only thing you need to get right at this moment is the gpioMinimumPulseLength. Only when you get decent wave patterns like this, you can look at the maximumtimebetweenimpulses: An example of noisefree data Please take one step at the time: if you move the magnet, or add another one, make a recording and see what happens to the signal. Then you start increasing gpioMinimumPulseLength. When I look at the visualisation of 2023-01-26_16-03-16_raw.csv, it looks familiar aside from the noisy small spikes (which gpioMinimumPulseLength is designed to fix). So getting back to that type of signal is important. Make sure that you know what you change and if this improves or worsens the situation. |
Beta Was this translation helpful? Give feedback.
-
|
First an apology and correction: the graph's data in the posting from Jan 27th apparently was not taken from 2023-01-26_16-03-16_raw.csv but probably from 2023-01-25_10-51-48_raw.csv.gz.gz](https://github.com/laberning/openrowingmonitor/files/10500689/2023-01-25_10-51-48_raw.csv.gz), Secondly: I loaded 2023-01-25_10-51-48_raw.csv.gz into a spreadsheet, filtered all values below 0,01 second and above 0.01 seconds and did separate graphs on both filtered datasets. I chose 0,01 because it was a safe distance from what I considered to be the lowest sensible stroke data which was 0,02. The lower image shows the curve for data above 0.01. I guess that ORM could work with this data and produce sensible results. The upper image is the data below 0.01. Strangely enough it shows traces of the power curve. To me that means that the bounce timing depends on the speed of the data reading. Seems weird but I don't have any experience with reed switches. Maybe @Abasz can shed some light on this. The practical implications: if values below a certain threshold seconds can be removed from the data stream we should be fine. If I understand the purpose of gpioMinimumPulseLength correctly it can be setup to do just that. However that threshould would be 0.01 seconds which would equate to a gpioMinimumPulseLength value of 1,000,000 (one million). As values of up to 500 are recommended that seems somewhat extreme. @JaapvanEkris, what do you think? It would also require that the data quality from that file would need to reached again which currently does not seem to be the case - there is hardly any power curve visible in the latest csvs. Cheers, |
Beta Was this translation helpful? Give feedback.
-
|
Just a thought - a possible explanation for the 'shadow power curve' (I like that phrase :)) hidden in the bounce values: could this be caused by centrifugal forces? |
Beta Was this translation helpful? Give feedback.
-
It should :)
I assume, as the flywheel spins faster, the magnetic fields that trigger the bounce also follow faster.
A bit clarification on how gpioMinimumPulseLength works: pgpio uses it to determine the minimum LENGTH of the signal. To put it simply, the magnet should be seen for x us before the gpio driver considers it a valid signal and generates a currentDt. Otherwise it will be ignored. general idea is that the main signal from a magnet is strong and long, where the magnetic fields causing the bounce are weaker and shorter. So this looks at the length of the signal itself, NOT at any time between this magnet and the next. This is a fundamental different approach with minimumTimeBetweenImpulses, which looks at the time between an impulse and the next impulse. I admit that a bouncing switch could in theory be combatted either by gpioMinimumPulseLength and minimumTimeBetweenImpulses, but in designing the new engine we explicitly chose the earlier. This is because the gpio driver is designed to combat bounce that way, and at that level, you can leverage the weakness of the signal to distinguish between the real signal and the noise, which is a much cleaner and robust solution. Using minimumTimeBetweenImpulses has the huge disadvantage that a misaligned magnet or missed signal would destroy the rhythm, and as the time between impulses varies as well, it isn't guaranteed to filter all noise anyway. |
Beta Was this translation helpful? Give feedback.
-
Exactly. Actually, I wrote a detailed answer (with good charts) but github did not post it for some reason and I dont have the charts anymore... The slower the speed the reed spends more time at the edge of the trigger point hence having longer bounce periods. But the point is that the magnet should spend sufficient time pulling the reed to high (that is actually recorded as low on the PI due to the inversion effect of the pull up resistor) and via Also I recall that actually changing on the MCU (Esp32) when I changed the |
Beta Was this translation helpful? Give feedback.
-
|
Hi, reed is close to magnet any help? |
Beta Was this translation helpful? Give feedback.
-
|
The wave form is better now: at least it resembles to something of a power curve. start increasing |
Beta Was this translation helpful? Give feedback.
-
|
gpioMinimumPulseLength: 100 empty csv gpioMinimumPulseLength: 150 |
Beta Was this translation helpful? Give feedback.
-
So you changed more than one thing at a time... |
Beta Was this translation helpful? Give feedback.
-
|
I changed magnet, now ORM doesn't reconize nothing all is stopped. // rowerSettings: rowerProfiles.DEFAULT, |
Beta Was this translation helpful? Give feedback.
-
|
webserver running on port 80 |
Beta Was this translation helpful? Give feedback.
-
|
I can come back easily if you think is better.
I give up 4 Magnets and change to one.
I put it in the Middle rather than the circumference.
I tried to change single magnet because the 0.00x values are still present.
With neodymium magnet Nothing doesn’t work anymore.
Last topic is the best result in all this e test even if isn’t good enough
What should I do?
Il giorno mar 31 gen 2023 alle 20:07 Jaap van Ekris <
***@***.***> ha scritto:
… Hi, I learn how check csv file and with 4 magnets all result are
unusefull. I find magnet from economic chinese bike monitor and I put it in
the middle the wheel radius.
So you changed more than one thing at a time...
—
Reply to this email directly, view it on GitHub
<#115 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A5AGSVGZVTBFUZP4Z2JCTYLWVFPGTANCNFSM6AAAAAAT5SGDXM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
look, your issue is hardware related. Its not an issue with ORM. We cannot debug hardware remotely. It can be 100 thing that could be an issue starting from too much vibration that the reed cannot handle ending at faulty circuit... You need to try changing the hardware (i.e. the reed, the magnet, their placement, etc.). I recommend researching and reading about how to improve reed signal. Its clear that the your reed does not produce a stable signal for sufficient time. I used this reed: https://pdf1.alldatasheet.com/datasheet-pdf/view/489462/DBLECTRO/MS-217-3.html The only thing I can tell, you based on the information you provided so far, is that your setup does not provide a stable signal for sufficient time. This means that the magnet is not triggering the reed for as long as it is needed. Play with the magnet and the reed placement. change the magnet to even bigger (if the previous magnet worked better than the neodymium go back to that and change something else). there are plenty of things that can be done. But its important that you only change one thing at the time and if it improves keep the change and start changing something else until the results are good. |
Beta Was this translation helpful? Give feedback.
-
I wouldn't know what is better, because you keep changing everything. There is no perfect solution you can copy, that is for you to find out for your machine. We can help you, but as said by everybody in this thread: stop changing everything each and every time. Yesterday, two people indicated you should increase the gpio impulse length to get a decent signal. So you change the entire setup so nothing works anymore and we are back to the situation we were a week ago.
And nothing works anymore, and nobody has a clue why. You can't even identify what change caused the issues.
And you ignored what @Abasz and @Gordon-Shumway2 said about start changing gpio settings. You can't expect people to help you if you keep ignoring their good advice and keep messing up as a result. |
Beta Was this translation helpful? Give feedback.
-
|
i'm sorry , my will was only to continue. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I'm going to test openrowingmonitor to my DIY openergo.
My flywheel is a 28'' bike wheel and I'll attach magnet on external perimeter.
I'll change the file rowerProfile.js with this settings, in your experiences would be ok?
do you have any suggestions?
thanks
`'use strict'
export default {
DEFAULT: {
numOfImpulsesPerRevolution: 4,
minimumTimeBetweenImpulses: 0.014,
maximumTimeBetweenImpulses: 0.5,
smoothing: 1,
flankLength: 2,
numberOfErrorsAllowed: 0,
naturalDeceleration: 0,
maximumImpulseTimeBeforePause: 3.0,
minimumDriveTime: 0.300,
minimumRecoveryTime: 1.200,
autoAdjustDragFactor: true,
flywheelInertia: 0.08,
dampingConstantSmoothing: 5,
dampingConstantMaxChange: 0.10,
magicConstant: 2.8
}
}
`
Beta Was this translation helpful? Give feedback.
All reactions