Closed DFBREB closed 7 years ago
Could you zip them?
You can zip the files first then attach the zip files
On 31 Dec 2016 11:10 pm, "DFBREB" notifications@github.com wrote:
When two micro:bits communicate using radio and the transmitting micro:bit sends a string to the receiving micro:bit and the reciving microbit converts it to an integer from 0 to 1023 which it hen sends as an output PWM signal via a pin (in my case P0 and P8) after 20 seconds to 200 seconds the receiving micro:bit freezes/hangs. The receiving micro:bit cannot be reset with the reset button in 90% of the cases.
The Beta Editor with Radio found at microbit.org is being used
However if the write analog lines are commented out the radio part of the system continues to work indefinitely.
Damien George is looking into this issue at this time.
Since this site does not support .hex or .py files I am unable to send scripts. David Booth
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5cASd1Y94HkBAMsUXM3xPeGDdeM_WRks5rNuECgaJpZM4LYopk .
Does the same issue happen on the microbit.co.uk editor? It uses a different micropython hex file to the .org
and mu
editor.
If the issue is not present, the problem might be a buggy out-of-date .hex
file generated by the .org
editor. A similar problem was reported in issue 391.
It has also been reported to the uFlash repository.
Hi Jez Thanks for the suggestion. I will try it. David
On 1 January 2017 at 13:16, Jez notifications@github.com wrote:
Does the same issue happen on the microbit.co.uk https://www.microbit.co.uk/app/#create:xyelfeeditor? It uses a different micropython hex file to the .co.uk and mu editor.
If the issue is not present, the problem might be a buggy out-of-date .hex file generated by the .co.org editor. A similar problem was reported in issue 391 https://github.com/bbcmicrobit/micropython/issues/391.
It has also been reported to the uFlash https://github.com/ntoll/uflash/issues/33repository.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-269902664, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf7CyUBcdl8qtA-qEK1kIUWV0JXIJks5rN6dIgaJpZM4LYopk .
I had a look at this and could confirm the lock-up of the receiver. But the firmware that @DFBREB used is not the latest firmware, in particular it didn't have the recent fixes to PWM. So I'd suggest trying the same code with the latest firmware and going from there.
Just to check, where does the user get the latest firmware from and how do they install it?
On 6 January 2017 at 11:54, Damien George notifications@github.com wrote:
I had a look at this and could confirm the lock-up of the receiver. But the firmware that @DFBREB https://github.com/DFBREB used is not the latest firmware, in particular it didn't have the recent fixes to PWM. So I'd suggest trying the same code with the latest firmware and going from there.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-270889783, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5cAaw4qT0H9gS0TzuL2ahD1Xr32gf8ks5rPit2gaJpZM4LYopk .
Hi Damien I am glad you identified the problem. However I do not have a clue how to get the latest firmware installed on my three micro:bits and would be very pleased if you could give me step by step instructions on how to do this. I am sure it would be appreciated by the other users who have reported the same problem Thank you David
On 6 January 2017 at 11:54, Damien George notifications@github.com wrote:
I had a look at this and could confirm the lock-up of the receiver. But the firmware that @DFBREB https://github.com/DFBREB used is not the latest firmware, in particular it didn't have the recent fixes to PWM. So I'd suggest trying the same code with the latest firmware and going from there.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-270889783, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf-_shI0IBUFyvmFkmvRf6oZMMuQFks5rPit3gaJpZM4LYopk .
Just to check, where does the user get the latest firmware from and how do they install it?
It looks like uflash/mu use an older version (the one before the PWM fix), so you'll need to use a raw .hex file instead, and tools/makecombinedhex.py from this repo to combine the firmware with your scripts.
I have put a pre-built version of the latest firmware at: https://micropython.org/resources/firmware/microbit-micropython.hex
HI Damien Thank you I am not very proficient at firmware manipulation but I will see how I get on. Regards David Booth
On 10 January 2017 at 03:45, Damien George notifications@github.com wrote:
Just to check, where does the user get the latest firmware from and how do they install it?
It looks like uflash/mu use an older version (the one before the PWM fix), so you'll need to use a raw .hex file instead, and tools/makecombinedhex.py from this repo to combine the firmware with your scripts.
I have put a pre-built version of the latest firmware at: https://micropython.org/resources/firmware/microbit-micropython.hex
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-271479039, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf-BkmHK-hqmGcR316xADMxBXkf23ks5rQv7LgaJpZM4LYopk .
Hi @DFBREB,
I'll see if I can help. In order to do so it'd be wonderful to know what operating system you're running. Also, do you have Python 3 installed..? Given this information I should be able to provide a "baby steps" (but definitely not baby-ish) instructions for you. Hopefully, you'll have fun and see how these sorts of things fit together and learn something new..! :smile:
In any case, I want to help in any way that I can.
N.
David (Booth)
Just a quick note here, for completeness. Nicholas came up with a fantastically simple way to make it possible for you to test this fix for us, in an amazing flash of inspiration last night!
I've sent the necessary instructions to you directly, but David if you could report back to this github ticket how this testing goes and whether Damien's PWM fix does indeed fix your specific problem?
As I understand it, this PWM fix will make it into a future release of Mu, but it's not quite there yet, as it is blocked waiting for some other fixes to be completed first.
David (Whale)
On 11 January 2017 at 17:54, Nicholas Tollervey notifications@github.com wrote:
Hi @DFBREB https://github.com/DFBREB,
I'll see if I can help. In order to do so it'd be wonderful to know what operating system you're running. Also, do you have Python 3 installed..? Given this information I should be able to provide a "baby steps" (but definitely not baby-ish) instructions for you. Hopefully, you'll have fun and see how these sorts of things fit together and learn something new..! 😄
In any case, I want to help in any way that I can.
N.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-271941349, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5cAb4WX4karGYCG1iiQNDfvrNbz10tks5rRRc5gaJpZM4LYopk .
Hi David Thank you and Nicholas for all this input. I have to go out in an hour but it will get top priority later today when I get back and I will report on progress. Thanks to you all. David B
On 12 January 2017 at 10:38, David Whale notifications@github.com wrote:
David (Booth)
Just a quick note here, for completeness. Nicholas came up with a fantastically simple way to make it possible for you to test this fix for us, in an amazing flash of inspiration last night!
I've sent the necessary instructions to you directly, but David if you could report back to this github ticket how this testing goes and whether Damien's PWM fix does indeed fix your specific problem?
As I understand it, this PWM fix will make it into a future release of Mu, but it's not quite there yet, as it is blocked waiting for some other fixes to be completed first.
David (Whale)
On 11 January 2017 at 17:54, Nicholas Tollervey notifications@github.com wrote:
Hi @DFBREB https://github.com/DFBREB,
I'll see if I can help. In order to do so it'd be wonderful to know what operating system you're running. Also, do you have Python 3 installed..? Given this information I should be able to provide a "baby steps" (but definitely not baby-ish) instructions for you. Hopefully, you'll have fun and see how these sorts of things fit together and learn something new..! 😄
In any case, I want to help in any way that I can.
N.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment- 271941349, or mute the thread https://github.com/notifications/unsubscribe-auth/ AD5cAb4WX4karGYCG1iiQNDfvrNbz10tks5rRRc5gaJpZM4LYopk .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-272130359, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf60zdpYO6rLi0rMYr2sAig_Z9VuFks5rRgKNgaJpZM4LYopk .
Hi Nicholas I have just picked up six emails from David W and you progressing this topic and I would like to thank you for your input. Today I will give priority to following these instructions and trying things out. If successful it could be the basis of a quick tutorial for others in my position until a more permanent fix comes out. Thanks again David
On 11 January 2017 at 17:54, Nicholas Tollervey notifications@github.com wrote:
Hi @DFBREB https://github.com/DFBREB,
I'll see if I can help. In order to do so it'd be wonderful to know what operating system you're running. Also, do you have Python 3 installed..? Given this information I should be able to provide a "baby steps" (but definitely not baby-ish) instructions for you. Hopefully, you'll have fun and see how these sorts of things fit together and learn something new..! 😄
In any case, I want to help in any way that I can.
N.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-271941349, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf3pp7Nzia_Xdd2rHN7_hHHa9Ga5dks5rRRc6gaJpZM4LYopk .
Hi David
Nicholas's solution is brilliantly elegant. Thanks Nicholas!
I followed Nocholas's procedure and it was very easy to follow. I processed my Rx and two Tx hex files through the new editor and loaded them onto the three micro:bits. They work well without the RX freezing. However I had an early scare when the Rx micro:bit froze after 20 minutes. I checked the Rx battery and it was down to 2.81 volts on the micro:bit GND and +3 pins. So I replaced the batteries which showed 3.16V across the GND and +3. It then ran for two hours before freezing again and once more the battery was down to 2.81V. I checked the two Tx batteries and they are still going but are showing a much lower 2.47V and 2.18V ( I haven't replaced these for a couple of months).
So this is interesting. The freezing problem has been solved by Damien in software, but people should be aware that the problem can reoccur at a low battery voltage below 2.81V which may be below the limits of the micro:bit specifcation ( I have top check) but at which people may expect the micro:bit to continue working. However it is not going to be a problem for the Kitronik Motor Driver Board because it provides the board with a regulated voltage. I am currently doing a duration test on the Motor Driver Board but I suspect my transmitters are going to run out of power first.
I am looking to buy three AA battery power packs to replace the AAA battery packs as they would give a stand-alone Rx much longer life. So that's the next step.
I plan to use the new modified microPython editor for future python programming but it raises the question:- If Kitronik want to sell the Motor Driver Board for the general public to program a PWM solution, what do they have to be told. Do they need to go through the same procedure I went through to upgrade their Python editor or is it likely that a user using an older micro:bit will have it automatically upgraded in the near future?
Finally how do I report this so that the ticket concerned with the microPython system freezing is closed.
I will let Kevin know we are making progress but you might like to as well.
All the best David
On 12 January 2017 at 10:38, David Whale notifications@github.com wrote:
David (Booth)
Just a quick note here, for completeness. Nicholas came up with a fantastically simple way to make it possible for you to test this fix for us, in an amazing flash of inspiration last night!
I've sent the necessary instructions to you directly, but David if you could report back to this github ticket how this testing goes and whether Damien's PWM fix does indeed fix your specific problem?
As I understand it, this PWM fix will make it into a future release of Mu, but it's not quite there yet, as it is blocked waiting for some other fixes to be completed first.
David (Whale)
On 11 January 2017 at 17:54, Nicholas Tollervey notifications@github.com wrote:
Hi @DFBREB https://github.com/DFBREB,
I'll see if I can help. In order to do so it'd be wonderful to know what operating system you're running. Also, do you have Python 3 installed..? Given this information I should be able to provide a "baby steps" (but definitely not baby-ish) instructions for you. Hopefully, you'll have fun and see how these sorts of things fit together and learn something new..! 😄
In any case, I want to help in any way that I can.
N.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment- 271941349, or mute the thread https://github.com/notifications/unsubscribe-auth/ AD5cAb4WX4karGYCG1iiQNDfvrNbz10tks5rRRc5gaJpZM4LYopk .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-272130359, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf60zdpYO6rLi0rMYr2sAig_Z9VuFks5rRgKNgaJpZM4LYopk .
Hi Nicholas That was a brilliant solution, posted on the ticket which worked well. This is an extract from an email I sent to David W.
" I followed Nocholas's procedure and it was very easy to follow. I processed my Rx and two Tx hex files through the new editor and loaded them onto the three micro:bits. They work well without the RX freezing. However I had an early scare when the Rx micro:bit froze after 20 minutes. I checked the Rx battery and it was down to 2.81 volts on the micro:bit GND and +3 pins. So I replaced the batteries which showed 3.16V across the GND and +3. It then ran for two hours before freezing again and once more the battery was down to 2.81V. I checked the two Tx batteries and they are still going but are showing a much lower 2.47V and 2.18V ( I haven't replaced these for a couple of months).
So this is interesting. The freezing problem has been solved by Damien in software, but people should be aware that the problem can reoccur at a low battery voltage below 2.81V which may be below the limits of the micro:bit specifcation ( I have top check) but at which people may expect the micro:bit to continue working. However it is not going to be a problem for the Kitronik Motor Driver Board because it provides the board with a regulated voltage. I am currently doing a duration test on the Motor Driver Board but I suspect my transmitters are going to run out of power first.
I am looking to buy three AA battery power packs to replace the AAA battery packs as they would give a stand-alone Rx much longer life. So that's the next step.
I plan to use the new modified microPython editor for future python programming but it raises the question:- If Kitronik want to sell the Motor Driver Board for the general public to program a PWM solution, what do they have to be told. Do they need to go through the same procedure I went through to upgrade their Python editor or is it likely that a user using an older micro:bit will have it automatically upgraded in the near future? "
Since writing this I have had the receiver plugged into a Kitronik Motor Driver Board for about 7 hours working continuously, with the two transmitters that have been on the same 2 x AAA batteries for over 7 hours and incidentally are running at a battery voltage of just over 2V.
Thank you It made all the difference to have the step by step guide.
All the best David
On 11 January 2017 at 17:54, Nicholas Tollervey notifications@github.com wrote:
Hi @DFBREB https://github.com/DFBREB,
I'll see if I can help. In order to do so it'd be wonderful to know what operating system you're running. Also, do you have Python 3 installed..? Given this information I should be able to provide a "baby steps" (but definitely not baby-ish) instructions for you. Hopefully, you'll have fun and see how these sorts of things fit together and learn something new..! 😄
In any case, I want to help in any way that I can.
N.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-271941349, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf3pp7Nzia_Xdd2rHN7_hHHa9Ga5dks5rRRc6gaJpZM4LYopk .
Hi Damien Your patch was a great success.
Thank you David Booth
On 6 January 2017 at 11:54, Damien George notifications@github.com wrote:
I had a look at this and could confirm the lock-up of the receiver. But the firmware that @DFBREB https://github.com/DFBREB used is not the latest firmware, in particular it didn't have the recent fixes to PWM. So I'd suggest trying the same code with the latest firmware and going from there.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-270889783, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf-_shI0IBUFyvmFkmvRf6oZMMuQFks5rPit3gaJpZM4LYopk .
@DFBREB great, I'm glad it worked for you. The issue with the RX microbit freezing at 2.81v, while the TX's keep running down to around 2v, is very interesting. It could be because the RX microbit's pins (the ones outputting PWM) are connected to an external device and that device has its own voltage levels which can interfere with the microbit at low voltages.
Hi Damien
I am doing a test this morning in which I have switched the transmitter and receiver micro:bits just in case my first receiver micro:bit was a rogue microbit.
I cannot see any logical reason for the cut off at 2.81V on the receiver and not the transmitters, since in the first test I did all the micro:bits were just coupled to their battery cases and nothing else, and all three are transmitting and receiving the same number of times. However the event was reproducible with the initial set up.
When I put the receiving micro:bit in the Kitronik Motor Driver Board it gets its power from a stabilised unit in the Board and so never sees a voltage lower than 3V and so never fails as a result of voltage reduction.
I will keep you informed on the test.
All the best David.
On 13 January 2017 at 06:17, Damien George notifications@github.com wrote:
@DFBREB https://github.com/DFBREB great, I'm glad it worked for you. The issue with the RX microbit freezing at 2.81v, while the TX's keep running down to around 2v, is very interesting. It could be because the RX microbit's pins (the ones outputting PWM) are connected to an external device and that device has its own voltage levels which can interfere with the microbit at low voltages.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-272369976, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf8_YNbx3cuPJfB9cd5P4fXAWSQLuks5rRxcFgaJpZM4LYopk .
Hi Damien As I said I would, I have swapped two micro:bits and rerun the duration test with new 2 x AAA batteries. They ran for 5 hours with the reciever finally freezing when the battery voltage got to 2.64 volts which is lower than the previous set up which stopped at 2.81 volts. So there is obviously a variability due to the specific hardware. I do not see this as anything to be concerned about particularly as the receiver in the Kitronik application will be powered from a stabilised supply.
Kitronik may be using this software at BETT. At the moment the radio.config(power = 0) - the default. They will be using it within the range of their stand. Do you think that the power should be increase?
All the best David B
On 13 January 2017 at 06:17, Damien George notifications@github.com wrote:
@DFBREB https://github.com/DFBREB great, I'm glad it worked for you. The issue with the RX microbit freezing at 2.81v, while the TX's keep running down to around 2v, is very interesting. It could be because the RX microbit's pins (the ones outputting PWM) are connected to an external device and that device has its own voltage levels which can interfere with the microbit at low voltages.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-272369976, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf8_YNbx3cuPJfB9cd5P4fXAWSQLuks5rRxcFgaJpZM4LYopk .
Hi David I have rerun a duration test with fresh AAA batteries and this time the set up ran for 5 hours before the receiver battery voltage got to 2.64 Volts and the receiver froze. This is a lower voltage than the previous test when the receiver stopped at 2.81 V. I do not see this as anything to be concerned about as the Kitronik application drives the receiving micro:bit through a stabilsed 3V supply. Incidentally the transmitters which were still active had voltages of 2.6V and 2.3V.
All the best David
On 12 January 2017 at 10:38, David Whale notifications@github.com wrote:
David (Booth)
Just a quick note here, for completeness. Nicholas came up with a fantastically simple way to make it possible for you to test this fix for us, in an amazing flash of inspiration last night!
I've sent the necessary instructions to you directly, but David if you could report back to this github ticket how this testing goes and whether Damien's PWM fix does indeed fix your specific problem?
As I understand it, this PWM fix will make it into a future release of Mu, but it's not quite there yet, as it is blocked waiting for some other fixes to be completed first.
David (Whale)
On 11 January 2017 at 17:54, Nicholas Tollervey notifications@github.com wrote:
Hi @DFBREB https://github.com/DFBREB,
I'll see if I can help. In order to do so it'd be wonderful to know what operating system you're running. Also, do you have Python 3 installed..? Given this information I should be able to provide a "baby steps" (but definitely not baby-ish) instructions for you. Hopefully, you'll have fun and see how these sorts of things fit together and learn something new..! 😄
In any case, I want to help in any way that I can.
N.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment- 271941349, or mute the thread https://github.com/notifications/unsubscribe-auth/ AD5cAb4WX4karGYCG1iiQNDfvrNbz10tks5rRRc5gaJpZM4LYopk .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-272130359, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf60zdpYO6rLi0rMYr2sAig_Z9VuFks5rRgKNgaJpZM4LYopk .
I'm pretty sure that power level 0 means 0dBm, which will be the highest power level??
David
David Whale, B.Sc (Hons), MIET Software Engineer and IET Schools Liaison Officer, Essex
On 13 January 2017 at 15:42, DFBREB notifications@github.com wrote:
Hi Damien As I said I would, I have swapped two micro:bits and rerun the duration test with new 2 x AAA batteries. They ran for 5 hours with the reciever finally freezing when the battery voltage got to 2.64 volts which is lower than the previous set up which stopped at 2.81 volts. So there is obviously a variability due to the specific hardware. I do not see this as anything to be concerned about particularly as the receiver in the Kitronik application will be powered from a stabilised supply.
Kitronik may be using this software at BETT. At the moment the radio.config(power = 0) - the default. They will be using it within the range of their stand. Do you think that the power should be increase?
All the best David B
On 13 January 2017 at 06:17, Damien George notifications@github.com wrote:
@DFBREB https://github.com/DFBREB great, I'm glad it worked for you. The issue with the RX microbit freezing at 2.81v, while the TX's keep running down to around 2v, is very interesting. It could be because the RX microbit's pins (the ones outputting PWM) are connected to an external device and that device has its own voltage levels which can interfere with the microbit at low voltages.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment- 272369976, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf8_ YNbx3cuPJfB9cd5P4fXAWSQLuks5rRxcFgaJpZM4LYopk .
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-272473537, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5cAdMyZfrRLFjM4ty5GjrRdviAcyB5ks5rR5tOgaJpZM4LYopk .
Hi David No it's the lowest level but I will test its range out here at home but as you will see from the extract from the manual it suggests upping the power if there is interference. So I just wondered if anyone had experience of demonstration (power) in an exhibition environment within the bounds of an exhibition stand? EXTRACT The power (default=0) is an integer value from 0 to 7 (inclusive) to indicate the strength of signal used when broadcasting a message. The higher the value the stronger the signal, but the more power is consumed by the device. The numbering translates to positions in the following list of dBm (decibel milliwatt) values: -30, -20, -16, -12, -8, -4, 0, 4.
All the best David
On 13 January 2017 at 17:00, David Whale notifications@github.com wrote:
I'm pretty sure that power level 0 means 0dBm, which will be the highest power level??
David
David Whale, B.Sc (Hons), MIET Software Engineer and IET Schools Liaison Officer, Essex
On 13 January 2017 at 15:42, DFBREB notifications@github.com wrote:
Hi Damien As I said I would, I have swapped two micro:bits and rerun the duration test with new 2 x AAA batteries. They ran for 5 hours with the reciever finally freezing when the battery voltage got to 2.64 volts which is lower than the previous set up which stopped at 2.81 volts. So there is obviously a variability due to the specific hardware. I do not see this as anything to be concerned about particularly as the receiver in the Kitronik application will be powered from a stabilised supply.
Kitronik may be using this software at BETT. At the moment the radio.config(power = 0) - the default. They will be using it within the range of their stand. Do you think that the power should be increase?
All the best David B
On 13 January 2017 at 06:17, Damien George notifications@github.com wrote:
@DFBREB https://github.com/DFBREB great, I'm glad it worked for you. The issue with the RX microbit freezing at 2.81v, while the TX's keep running down to around 2v, is very interesting. It could be because the RX microbit's pins (the ones outputting PWM) are connected to an external device and that device has its own voltage levels which can interfere with the microbit at low voltages.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment- 272369976, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf8_ YNbx3cuPJfB9cd5P4fXAWSQLuks5rRxcFgaJpZM4LYopk .
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment- 272473537, or mute the thread https://github.com/notifications/unsubscribe-auth/ AD5cAdMyZfrRLFjM4ty5GjrRdviAcyB5ks5rR5tOgaJpZM4LYopk .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/micropython/issues/392#issuecomment-272489120, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtNf37oHhln-BHZNIaiG7S2W8ZDYspHks5rR62ogaJpZM4LYopk .
As I said I would, I have swapped two micro:bits and rerun the duration test with new 2 x AAA batteries. They ran for 5 hours with the reciever finally freezing when the battery voltage got to 2.64 volts which is lower than the previous set up which stopped at 2.81 volts. So there is obviously a variability due to the specific hardware. I do not see this as anything to be concerned about particularly as the receiver in the Kitronik application will be powered from a stabilised supply.
Thanks for testing it. I don't have a good answer as to why it would behave like this. In real applications one will just need to make sure that the power source is reliable enough.
Kitronik may be using this software at BETT. At the moment the radio.config(power = 0) - the default. They will be using it within the range of their stand. Do you think that the power should be increase?
Actually, the default is "power=6", which translates to 0 dBm. So the docs are wrong in this respect and will be fixed by #402.
So, no need to adjust the power level for the demo.
Regarding this issue: I'd say it can be closed now because the fixes to PWM are already there, just not yet in the firmware available in the online editors.
Hi @dpgeorge, I am having exact same problem as described in this thread. I tried to use the fix you provided: https://micropython.org/resources/firmware/microbit-micropython.hex and compiled my code with patched MicroPython in PythonEditor-master: https://github.com/bbcmicrobit/PythonEditor following steps in: https://support.microbit.org/support/solutions/articles/19000044801-how-to-use-an-updated-micropython-image. (Are these steps correct? How can I check that correct patched MicroPython is loaded on the board?) Unfortunately the "fix" did not work for me. If I use any PWM pin0.write_analog() together with radio.receive() or radio.receive() commands, after some random time the micro:bit crashes (unresponsive). I don't think my issue is anyhow relevant to power supply (I use reliable power sources); and I don't have any pins outputting PWM connected to any external devices... Please let me know if you need my *.py test scripts for diagnosing the issue.
Please let me know if you need my *.py test scripts for diagnosing the issue.
@y-kulk yes please.
@dpgeorge, Please find my scripts at the following DropBox shared link: https://www.dropbox.com/sh/dd08d7uosddy8e4/AADsoVoxSx6J5ultI6IZiq2va/RC_test_scripts?dl=0
Please read Instructions.txt. You'll need two Micro:bits for testing.
@y-kulyk thanks for supplying the files. Unfortunately you are still using the old, non-working version of the hex file. I can tell because there is no i2c.init method (which was added before the PWM fix).
I put a new version of the hex file at http://micropython.org/resources/firmware/microbit-micropython.hex which was built from 64a61dbf3beb6df525bd2f1f579d926afda47c97
To check that you have the correct version, at the REPL you can do:
>>> import microbit
>>> microbit.Image.blit
<function>
>>>
If it doesn't print <function>
but instead gives you the message AttributeError: type object 'MicroBitImage' has no attribute 'blit'
then you still have the old version.
@dpgeorge , Thanks for your comments. It works now for me (when I used makecombinedhex.py)
The reason it was not working before was that I followed steps in: https://support.microbit.org/support/solutions/articles/19000044801-how-to-use-an-updated-micropython-image but it looks like these are incorrect... Simply replacing firmware.hex does not actually replace the microbit-micropython.hex; which probably should be addressed as well. Thanks for the tip how to check if the "correct version used" as well!
@whaleygeek please can you correct the instructions..? Thank you!
@ntoll @dpgeorge What are the downsides to using the fixed MicroPython firmware hex here on the deployed editor?
I believe the compass calibration is broken since it writes to some arbitrary memory location that takes no account of MicroPython and the interpreter breaks. :-(
There is a fix for this by Mark, but we need to remove DAL and mbed related things to free up space so this fix and some other things can make it into the release.
Does this make sense?
@ntoll I'm not sure I get the feature interactions completely - is that version Damien posted (IE from 64a61db) more broken than what's currently deployed? Is it the case that there's currently not a way to build a fully working MicroPython base image? I think if we have to pick between PWM and compass calibration, I'd rather have PWM working with radio and a well documented way to use a previous editor version if compass was essential - @whaleygeek may have a different view based on the support requests he sees.
We have a long queue of people wanting reliable PWM (+radio) working in MicroPython. Generally the compass is one of the least used features, because its fiddly to get an accurate reading from it and the compass calibration needing to occur on each re-flash tars the user experience quite badly.
I'd vote for getting the PWM working again (like it used to) and working with radio at the same time.
is that version Damien posted (IE from 64a61db) more broken than what's currently deployed?
That version should be pretty stable, the only known difference is how the compass is calibrated but the calibration does work.
Is it the case that there's currently not a way to build a fully working MicroPython base image?
Of course, we can always build any of the commits from this repo, it just depends what features & bugs users want, eg:
But before we merge anything else we must first implement a proper versioning system so it's easy (for users and developers) to tell which version they have; see #370.
@y-kulyk - Can you please elaborate on how you got this to work re. replacing the microbit-micropython.py file as well as the firmware.py ?
The reason it was not working before was that I followed steps in: https://support.microbit.org/support/solutions/articles/19000044801-how-to-use-an-updated-micropython-image but it looks like these are incorrect... Simply replacing firmware.hex does not actually replace the microbit-micropython.hex; which probably should be addressed as well.
Hello,
It has been a while...
The problem was that the latest (when I used it - ~ a year ago) firmware had a bug and intermittently crashed MB if radio and PWM were used together.
I contacted someone in MB development and they sent me "previous" version of firmware, which did not suffer from the above issue (but di have some other limitation) as well as instructions how to compile script with different firmware included. I followed the instructions and it "just worked". Sorry, I can't elaborate because I don't have MB handy and don't quite remember the steps.
Regards,
ykulyk
From: jswanborough notifications@github.com Sent: 27 February 2018 16:59 To: bbcmicrobit/micropython Cc: y-kulyk; Mention Subject: Re: [bbcmicrobit/micropython] microbit hangs when using radio and PWM (#392)
@y-kulykhttps://github.com/y-kulyk - Can you please elaborate on how you got this to work re. replacing the microbit-micropython.py file as well as the firmware.py ?
The reason it was not working before was that I followed steps in: https://support.microbit.org/support/solutions/articles/19000044801-how-to-use-an-updated-micropython-image
How to use an updated MicroPython image : Supporthttps://support.microbit.org/support/solutions/articles/19000044801-how-to-use-an-updated-micropython-image support.microbit.org QUESTION. How do I use a more recent MicroPython image to generate my scripts? I have a patched .hex image how do I use this to load Python onto the micro:bit?
but it looks like these are incorrect... Simply replacing firmware.hex does not actually replace the microbit-micropython.hex; which probably should be addressed as well.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/bbcmicrobit/micropython/issues/392#issuecomment-368948771, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AZO6llYw7ETjRCRJkqVk616xp04xLMWMks5tZDRXgaJpZM4LYopk.
When two micro:bits communicate using radio and the transmitting micro:bit sends a string to the receiving micro:bit and the reciving microbit converts it to an integer from 0 to 1023 which it hen sends as an output PWM signal via a pin (in my case P0 and P8) after 20 seconds to 200 seconds the receiving micro:bit freezes/hangs. The receiving micro:bit cannot be reset with the reset button in 90% of the cases.
The Beta Editor with Radio found at microbit.org is being used
However if the write analog lines are commented out the radio part of the system continues to work indefinitely.
Damien George is looking into this issue at this time.
Since this site does not support .hex or .py files I am unable to send scripts. David Booth